How do you stop a business from losing millions of pounds because of a single computer hack or a missing data backup? That is the problem that IT risk management and compliance solve: they give you a structured way to identify what could go wrong, decide how much risk you are willing to take, and prove to auditors that you are following the rules. For your CISA exam, this is the single most important mental framework because almost every other topic (access control, encryption, business continuity) is just a specific tool used inside this bigger process.
Jump to a section
A simple way to picture Risk Management and Compliance
A home security system is a set of controls and processes for managing the risk of a burglary.
The system starts with an inventory of what is valuable inside the house – this is the asset identification. The homeowner then considers the threats: a window left open, a weak lock, or a fake delivery driver. Each threat has a likelihood and a potential impact. The homeowner decides to accept the risk of leaving a spare key under the mat but installs motion sensors and cameras to mitigate the risk of a break-in. The alarm company monitors the system 24/7, which is the detective control. The homeowner also has a safe for important documents, which is a preventive control.
Compliance comes from the local council's building code: the alarm must be registered, the locks must meet a certain standard, and the homeowner must prove the system is tested annually. If a break-in occurs, the homeowner reviews the footage to understand what went wrong – this is the incident response and lessons learned. The security system is not a one-time purchase; it requires regular patching (updating the software), testing (walking the perimeter), and adjusting (if a new window is added, it needs a sensor). This analogy maps precisely to IT risk management: you identify assets, assess threats, choose responses, implement controls, monitor continuously, and prove compliance to regulators or auditors.
Risk management is the process of identifying, analysing, and responding to the things that could hurt an organisation's IT systems and data. Imagine you are responsible for a small company that takes customer orders through a website. You need to think about what could go wrong: a hacker could steal credit card numbers, a power cut could take the site offline, an employee could accidentally delete the customer database, or a supplier could go out of business and leave you without critical software.
The first step is risk identification. You list every possible threat and vulnerability. A threat is something that can cause harm, like a hacker or a natural disaster. A vulnerability is a weakness that a threat can exploit, like an outdated software version or a weak password. The combination of a threat and a vulnerability creates a risk.
Once you have a list, you perform risk analysis. This means assigning a likelihood (how probable is it?) and an impact (how bad would it be?) to each risk. For example, a minor software bug might be very likely but have low impact – it just causes a small delay. A ransomware attack might be less likely but have catastrophic impact – it could stop the entire business for weeks. You then plot these risks on a grid, often called a risk matrix or heatmap. Risks in the top-right corner (high likelihood, high impact) demand immediate attention.
The next step is risk response. You have four options:
Avoid: stop the activity that creates the risk. For example, if a certain software feature is too risky, you simply do not build it.
Mitigate: reduce the likelihood or impact. This is the most common response. You install firewalls, encrypt data, train staff, and run backups.
Transfer: share the risk with someone else. The classic example is buying cyber insurance. Another is outsourcing a risky process to a vendor.
Accept: acknowledge the risk and take no action. This is only wise for low-likelihood, low-impact risks. You document why you accepted it.
After deciding on responses, you implement controls. Controls are specific measures that enforce your risk response. They come in three categories: preventive controls stop bad things from happening (e.g., a lock on a server room door), detective controls identify when something bad has happened (e.g., an intrusion detection system that alerts you to an attack), and corrective controls fix things after a problem (e.g., restoring data from a backup).
Now, compliance. Compliance means making sure the organisation follows external laws, regulations, and internal policies. For IT, this often means standards like the General Data Protection Regulation (GDPR) in Europe, the Health Insurance Portability and Accountability Act (HIPAA) in healthcare, or the Payment Card Industry Data Security Standard (PCI DSS) for credit card processing. Compliance is not optional – it is enforced by law or by contracts. An auditor (like a CISA-certified professional) will examine your risk management process, your controls, and your evidence to see if you are following the rules.
The final piece is continuous monitoring. Risk management is not a one-off project. New threats appear every day (e.g., a new type of virus), and the business changes (e.g., the company launches a new product). You need to reassess risks regularly, test controls, and update your documentation. This is what the CISA calls 'evaluating IT risk management and compliance processes' – you are not just building the system; you are checking that it still works.
What does this replace? Before formal risk management, organisations often relied on 'gut feeling' or a 'checklist' approach. They might buy a firewall because everyone else does, without thinking about what specific risks they face. That approach leaves gaps. Formal risk management ensures every control has a purpose and every risk is accounted for. It turns security from guesswork into a science.
Identify Assets and Threats
First, you list everything of value (databases, servers, customer data) and everything that could harm them (hackers, human error, natural disasters). This step creates the raw material for all later analysis. Without a full list, you will miss critical risks.
Analyse Each Risk (Likelihood and Impact)
For each identified risk, you estimate how likely it is to occur (e.g., once in 10 years vs. once a week) and how severe the damage would be (e.g., £1,000 loss vs. £1 million loss). This is called risk analysis. You use this to prioritise which risks need immediate action.
Choose a Risk Response
Based on the analysis, you decide what to do for each risk: avoid (stop the activity), mitigate (reduce it), transfer (buy insurance or outsource), or accept (do nothing and document why). This step turns analysis into a plan.
Implement Controls
You deploy specific measures (technical or procedural) to enforce your chosen response. For mitigation, you install firewalls, encryption, and training. For transfer, you sign a contract with an insurance company. This is where the abstract plan becomes real.
Monitor and Review Continuously
You check the controls are working (e.g., review logs, run vulnerability scans) and reassess risks regularly. When a new threat appears or the business changes, you go back to step 1. This ensures the risk management process stays current and effective.
An IT professional, often called a risk manager, security analyst, or compliance officer, lives this process every day. Here is a concrete scenario.
Imagine you are the IT security lead at a mid-sized retail company that is about to launch an online payment feature. The company has never handled credit card data before. Your first job is to identify the new risks. You sit down with the development team and ask: 'Where does the credit card data go?' You map the flow: the customer's browser sends the data to your web server, then to a third-party payment processor, and the processor sends back a confirmation. The credit card number never touches your database. That is a big deal – it limits your risk. But you still have a vulnerability: if a hacker compromises your web server, they could intercept the card data as it passes through. You note this as a risk with high impact (losing customer trust, fines) and medium likelihood (your web server is well patched, but not perfect).
Now you choose a risk response. You cannot avoid the feature – the business needs it to grow. You cannot transfer all the risk – the company still handles the data in transit. So you decide to mitigate. You implement a control: you require encryption between the browser and the server (HTTPS) and between the server and the processor (a secure API). You also install a web application firewall (WAF) to block common hacking attempts. These are preventive controls. You also set up logging to record every transaction – that is a detective control. And you write a procedure for what to do if a breach happens – that is a corrective control.
Next, compliance. The company now needs to follow PCI DSS, the standard for handling credit cards. You must fill out a Self-Assessment Questionnaire (SAQ) to prove that you have the right controls. You collect evidence: screenshots of the encryption settings, logs showing the WAF is active, and a signed policy stating that employees are trained. An external auditor will review this evidence once a year. If you fail the audit, the company could lose the right to accept credit cards – a catastrophic business risk.
Your day-to-day work also includes monitoring. You check the logs every morning for suspicious activity. You run a vulnerability scanner once a month. When a new critical vulnerability is announced for your web server software (this happens roughly every week), you have to decide whether to apply the patch immediately (which might break the website) or wait (which leaves you exposed). That is a risk decision you make using the same framework.
Finally, you report to senior management. They do not care about technical details like 'TLS 1.2' – they care about risk levels. You prepare a dashboard showing: high risks (0 this quarter), medium risks (3, being addressed), low risks (12, accepted). You explain that the new payment feature increased the risk score slightly but that the controls brought it back down. Management uses this report to decide if they need to spend more on security or if they are comfortable. That is the tangible output of risk management: informed business decisions.
The CISA exam tests your ability to evaluate risk management and compliance processes, not just memorise terms. Expect questions that present a scenario and ask you to identify the correct next step or the most appropriate type of control.
Here are the exact concepts they love to test:
The four risk response options (avoid, mitigate, transfer, accept). You will be given a scenario and asked which one applies. A common trap is confusing 'transfer' (buying insurance, outsourcing) with 'mitigate' (installing controls). Remember: if the company still bears some residual risk after the action, it is mitigation, not transfer.
The difference between preventive, detective, and corrective controls. They will list a control (e.g., a backup) and ask you to classify it. Backup is corrective because it fixes after a failure. A firewall is preventive. An audit log is detective.
The Risk Management process (identification, analysis, response, monitoring). Questions often give a step out of order and ask what should come next. For example: 'The IT team has identified a list of risks. What should they do next?' Answer: perform risk analysis (assign likelihood and impact).
Key frameworks: COBIT is a popular governance framework the exam loves. Know that COBIT stands for Control Objectives for Information and Related Technologies. It is a set of best practices for managing IT. Also know ISO 27001 (an international standard for information security management) and the NIST Cybersecurity Framework (a US government guide). You do not need deep details, just the purpose of each.
Residual risk vs. inherent risk. Inherent risk is the risk before you apply any controls. Residual risk is the risk that remains after controls. For example, even with a firewall, there is still some residual risk of a hacker getting through (e.g., via a phishing email). Auditors want to know that management has accepted the residual risk.
The role of the risk owner. CISA tests that every risk must have an owner – a person who is responsible for monitoring and managing that risk. The owner is typically a business manager, not the IT team. The IT team implements the controls, but the business owns the risk.
Trap patterns:
They will give you a control that sounds like it fits one category but actually fits another. For example, 'a smoke detector in the server room' is a detective control (it detects fire), but many students call it preventive.
They will offer an answer that is technically correct but not the best next step in the process. Always ask: 'What is the logical sequence?'
They will test your spelling of 'management' as 'managment' – no, but they will use trick wording like 'which of the following is NOT a risk response option?' with 'avoid' replaced by 'eliminate'. The correct term is 'avoid'.
They may present a compliance requirement that is actually a different one than what the scenario calls for. For example, they describe a hospital's patient records – the relevant regulation is HIPAA (Health Insurance Portability and Accountability Act), not PCI DSS.
Key definitions to memorise:
Threat: something that can cause harm (e.g., a hacker).
Vulnerability: a weakness that can be exploited (e.g., an unpatched server).
Risk: the combination of a threat exploiting a vulnerability, causing harm.
Control: a measure that modifies risk.
Inherent risk: risk before controls.
Residual risk: risk after controls.
Risk management is the process of identifying, analysing, and responding to risks, not just buying security tools.
There are exactly four risk response options: avoid, mitigate, transfer, and accept – and each has a specific business context.
Controls are classified as preventive, detective, or corrective, and a good security programme uses all three types in layers.
Compliance means following external rules (like GDPR or PCI DSS), but being compliant does not guarantee you are secure.
Inherent risk is the risk before any controls; residual risk is what remains after controls are applied and must be formally accepted by management.
Risk ownership belongs to a business leader, not the IT department, because risk decisions involve business trade-offs.
Risk management is a continuous cycle, not a one-time project – new threats appear every day.
Every risk must be documented and have an assigned owner – you cannot simply ignore a risk even if you think it is very unlikely.
These come up on the exam all the time. Here's how to tell them apart.
Inherent Risk
Risk level before any controls are applied
Calculated as the raw combination of threat and vulnerability
Used to decide how much control investment is needed
Residual Risk
Risk level that remains after controls are implemented
Must be formally accepted by management
The actual risk the organisation lives with
Preventive Control
Stops an incident from occurring
Example: a firewall blocking a malicious connection
Often the first line of defence
Detective Control
Identifies an incident while or after it happens
Example: an intrusion detection system alert
Provides visibility and triggers corrective actions
Mitigate
Reduces likelihood or impact through internal actions
Organisation retains the risk but lowers it
Example: installing encryption and training staff
Transfer
Shifts part of the risk to a third party
Organisation still has some residual risk
Example: buying cyber insurance or outsourcing to a vendor
Risk Assessment
The process of identifying and analysing risks
Produces a list of risks with likelihood and impact ratings
Answers the question: 'What could go wrong?'
Risk Treatment
The process of deciding how to respond to each risk
Produces a plan of actions (controls, insurance, acceptance)
Answers the question: 'What are we going to do about it?'
Compliance
Following specific external rules and regulations
Measured by passing an audit checklist
Standardised across organisations (e.g., PCI DSS)
Security
Reducing actual risk to an acceptable level
Measured by incident frequency and severity
Tailored to each organisation's unique risk profile
Mistake
Risk management is just about installing antivirus software and firewalls.
Correct
Risk management is a structured process of identifying, analysing, and responding to risks. Installing antivirus is just one control within that process. The process itself matters more than any single tool.
Beginners focus on tangible products (firewalls, antivirus) because they are concrete. The abstract process of assessing likelihood and deciding on a response feels less immediate. But without the process, you might spend money on the wrong controls.
Mistake
Compliance and security are the same thing. If you pass an audit, you are secure.
Correct
Compliance means following rules (e.g., a law or standard). Security means actually reducing risk. It is possible to be compliant (meet every checkbox) but still be insecure (e.g., you have the required encryption but your employees use passwords that are 'password123'). The CISA exam stresses that compliance is a baseline, not a guarantee of security.
People naturally want a clear pass/fail line. Compliance audits provide that. Security is fuzzy and never complete. Beginners latch onto compliance as 'being done' when in reality security is a continuous effort.
Mistake
If a risk has low likelihood, you do not need to do anything about it.
Correct
You must still document your decision to accept the risk. Risk acceptance is one of the four official response options, and it must be intentional and approved by management. You cannot just ignore a risk because you think it is unlikely; you need formal acceptance.
It feels intuitive to ignore unlikely events. But auditors expect evidence that every risk was considered, not just the scary ones. Also, a low-likelihood risk with catastrophic impact (e.g., a meteor hitting the data centre) still requires a decision – probably accept, but documented.
Mistake
Risk management is only for the IT department. The business just pays the bills.
Correct
Risk management must involve business leaders. The risk owner is always a business person because they understand the value of the data and the impact of a loss. IT implements controls, but the business decides how much risk to accept.
IT professionals often feel they own 'security,' but in reality, security decisions have business trade-offs (e.g., adding more security makes the system slower). The business must make those trade-off decisions. Beginners see IT as the sole responsible party because they think security is purely technical.
Mistake
Once you have done a risk assessment, you are done for the year.
Correct
Risk management is a continuous process. New threats emerge daily (e.g., a new zero-day vulnerability), and the business environment changes (e.g., a new product launch). The CISA framework requires ongoing monitoring and periodic reassessment (e.g., quarterly or annually).
People treat risk assessments like a homework assignment: complete once and hand in. But in cyber security, the threat landscape shifts constantly. Beginners think 'we did the assessment' equals 'we are safe' – it does not.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A threat is something that can cause harm, like a hacker or a fire. A vulnerability is a weakness that the threat can exploit, like an unpatched software bug or a door without a lock. Risk is born when a threat meets a vulnerability.
You need to know the purpose of each major regulation (e.g., GDPR protects EU personal data, HIPAA protects US health data) and which scenarios they apply to. You do not need to recite specific article numbers or fine amounts.
Residual risk is the risk that remains after you have applied all your controls. It matters because management must formally accept it. No control is 100% effective, so there is always some leftover risk that must be acknowledged and documented.
The auditor reviews documentation: the risk assessment report, the risk treatment plan, evidence of control implementation (e.g., firewall configurations), and evidence of monitoring (e.g., audit logs). They also interview staff to ensure the process is actually followed, not just written down.
No. Insurance transfers the financial impact but not the reputational damage, customer trust loss, or legal liability for negligence. You still need to mitigate risks properly. Also, some risks are uninsurable (e.g., deliberate fraud by employees).
A control is a measure that modifies risk. The three types are preventive (stops a problem before it happens, like a lock), detective (identifies a problem as it happens, like an alarm), and corrective (fixes things after a problem, like a backup restore).
You've finished Risk Management and Compliance. Continue through the CISA study guide to build a complete picture of the exam.
Done with this chapter?