Risks are an inevitable part of operating a business. However, the success of your organization depends on your ability to manage and respond to threats appropriately. Data collected by Gartner shows that revenue-motivated vendor license compliance audits are increasing for organizations of all sizes and industries. Software asset managers must understand audit trends and prepare the organization against compliance risk and unbudgeted costs.
As organizations are more likely than ever to be audited by their software vendor, one of the top questions we are asked is, “How at risk is my organization in the event of an Oracle audit?” In this blog, you will be able to quantify your organization’s Oracle audit risk through traditional risk-calculating practices in a risk matrix.
Our risk analysis matrix allows you to plan responses to the most catastrophic risks, contain moderate risks, and monitor less severe ones. Use it to identify your level of risk, the impact on your organization, and the mitigation action needed. When planning responses, factor in the time it will take to learn expert-level licensing deployment and OLSA(s) (Oracle License Service and Agreements) and the minimum staff needed to conduct business amid an audit.
How is Oracle Audit Risk Quantified?
Severity
Insignificant — Risks that bring no real negative consequences or pose no significant threat to the organization or project.
Minor — Risks that have a small potential for negative consequences but will not significantly impact overall success.
Moderate — Risks that could potentially bring negative consequences, posing a moderate threat to the project or organization.
Critical — Risks with substantial negative consequences that will seriously impact the success of the organization or project.
Catastrophic — Risks with extremely negative consequences that could cause the entire project to fail or severely impact the daily operations of the organization. These are the highest-priority risks to address.
Likelihood
Unlikely — Extremely rare risks, with almost no probability of occurring.
Seldom — Risks that are relatively uncommon but have a small chance of manifesting.
Occasional — Risks that are more typical, with about a 50/50 chance of taking place.
Likely — Risks that are highly likely to occur.
Definite — Risks that are almost certain to manifest. Address these risks first.
Oracle Audit Risk Catagories
Low — The consequences of the Oracle audit risk are minor, and it is unlikely to occur. These types of risks are generally ignored and often color-coded green.
Medium — Somewhat likely to occur, these risks come with slightly more severe consequences. If possible, take steps to prevent medium audit risks from happening, but remember that they are not high-priority and should not significantly affect the organization or project’s success. These risks are often color-coded yellow.
High — These are serious Oracle audit risks that have significant consequences and are likely to occur. Prioritize and respond to these risks in the near term. They are often color-coded orange.
Extreme — Catastrophic risks that have severe consequences and are highly likely to occur. Extreme Oralce audit risks are the highest priority. You should respond to them immediately, as they can threaten the success of the organization or project. They are often color-coded red.
Quantify Your Organization’s Oracle Audit Risk Assessment
Now that you understand the basics of quantifying risk take our assessment to understand your organization’s current Oracle audit risk exposure. Answer each question and total your points for your personal risk assessment.
What is the size of your environment?
| 50 workloads | 0 |
| 250 workloads | 1 |
| 1,000 workloads | 2 |
| 10,000+ workloads | 3 |
Why this is important: We do the initial assessment based on the magnitude of small, medium, large, or extra-large. Typically, the more workloads you are running, the more complex your deployment increasing the probability of compliance issues.
How often do you check your software licensing usage?
| In real-time | 0 |
| Once a quarter | 1 |
| Once a year | 2 |
| Never | 3 |
Why this is important: Depending on the size of your IT department, unless you are the only person involved in the licensing deployment, you can never be sure that you are in compliance at any given moment. Even if you are the only person who touches the licensing, you can still make an error that would violate the license terms, which would result in needing Enterprise edition. (i.e., It’s possible to activate the tuning pack in Oracle Standard Edition. We’ve also seen instances of customers applying Oracle patches, which change their configuration from Standard to Enterprise unbeknownst to them.)
How are you running your Oracle workloads?
| Physical: (i.e., Dedicated hardware, LPARs, etc.) | 0 |
| Virtual: (i.e., VMware HyperV Oracle VM) | 1-3 |
If virtual, where?
| Dedicated Cluster | 1 |
| Host Affinity | 2 |
| CPU Affinity | 3 |
Definitions:
Dedicated Cluster — A group of connected machines you are licensing all of it for Oracle purposes.
Host Affinity — A single machine in a group of machines that is licensed for Oracle.
CPU Affinity — A portion of the processors in a machine that is licensed for Oracle.
Why this is important: Anytime you virtualize your environment, you are complicating the licensing terms. Additionally, Oracle is known to target virtualized customers and implement strict enforcement of their OLSA(s).
Do you have High Availability requirements?
Definition: High Availability requirements are systems that operate continuously without failure, typically through redundant components.
| No, we do not have high availability requirements. | 0 |
| Yes, we do have high availability requirements. | 1-3 |
If Yes: Are you leveraging the “Failover Rule” to meet those HA requirements?
| No, we’re not leveraging the failover rule. | 1 |
| Yes, we’re leveraging the failover rule. | 3 |
Why this is important: When utilizing High Availability, it increases the chances that you may be out of compliance depending on how you’ve deployed your workloads. The failover rule complicates the chances of you remaining compliant.
Do you have Disaster Recovery requirements?
Definition: Disaster Recovery, also commonly referred to as DR, is security planning that aims to protect an organization from the effects of significant adverse events. DR allows organizations to maintain or quickly resume mission-critical functions following a disaster.
| No, we do not have Disaster Recovery requirements. | 0 |
| Yes, we do have Disaster Recovery requirements. | 1-3 |
If Yes: Are you leveraging the “Testing Rule” to meet those DR requirements?
| No, we are not leveraging the testing rule. | 1 |
| Yes, we are leveraging the testing rule. | 3 |
Why this is important: If you have disaster recovery requirements, it means it has license implications. If an Oracle software license is deployed somewhere else or set up to run somewhere else in the event of a failure, it could present compliance issues.
Total your score.
Interpreting Your Score
1-2
You have a low Oracle audit risk
Your organization has a small investment with Oracle in a non-virtualized environment. You are solely responsible for the license deployment and check your licensing regularly using a SAM (software asset management) tool or you’ve hired a third-party manager to regularly check your compliance.
3-6
You have a medium Oracle audit risk
You know you need to check your licensing more than you currently do, but you rely on the fact that you have not been audited by Oracle thus far. Your organization has a company requirement, such as Disaster Recovery, that complicates your deployment, but you believe you have a good understanding of your licensing utilization.
7-10
You have a high Oracle audit risk
You check your licenses once a year or less, and you have a virtual deployment accessing failover and/or testing rules. Additionally, you may find that there are a lot of “cooks in the kitchen,” as many people have control over Oracle license deployments opening the door for errors.
11+
You have an extremely high Oracle audit risk
Often the assumption of knowing where your Oracle deployments are without verification is what lands organizations in the high-risk bucket. There is most likely complete independence between your finance department and IT department, or you obtained Oracle licenses through a third party, causing a lot of confusion about who is truly responsible for the licensing.
Conclusion
A risk rating matrix is simply a tool to help guide your decision-making. Your risk management team should always carefully analyze the risks themselves before deciding how to prevent, mitigate, or respond to a current or potential risk.
Regardless of your risk factor, if you don’t have a clear view of your licensing deployment continuously, you are leaving the door open for Oracle to find compliance issues in your licensing. At a minimum, you should set up internal audits to review your deployment and identify any potential compliance issues that could cause you to fall out of favor with your licensing contract.
Your next steps
The next step in ensuring compliance would be a Compliance and Optimization Review (COR). The COR will allow you to get a snapshot of your Oracle deployment(s) at that moment in time. It will review your contracts and deployment and determine your utilization, providing you with recommendations to eliminate compliance issues/threats, retire unused licenses, and reduce support costs.
Most larger organizations have turned to SAM (Software Asset Management) tools to monitor their deployments. When vetting SAM tools, knowing their refresh cycle is critical. Does their system refresh hourly, weekly, monthly, or quarterly? Real-time monitoring and alerting systems are the only real solution to preventing compliance issues.
Lastly, having a SAM tool to automate your licensing compliance checks is incredibly beneficial to saving you time and money. However, the tool alone falls short in the department of providing expert advice. You can’t ask your SAM tool “XYZ” about licensing. Tools cannot advise you on how to upgrade your hardware without licensing issues or negotiating contract terms with Oracle. This is when having a team of licensing experts at your disposal is a necessity. Consider a comprehensive SAM managed service like the ArxPlatform to ensure compliance and completely transfer your Oracle audit risk exposure to LicenseFortress.
