Risk, Governance, and Compliance
Translate policy, regulation, and business risk into security requirements teams can actually implement.
- Certification
- CompTIA Security+
- Recommended study time
- 5h 35m
- Status
- Not started
Recommended study time
About 5h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson22 min
About 2,833 words at a careful technical reading pace.
- Second pass with notes13 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Explain how policies, standards, procedures, and guidelines relate.
- Apply risk assessment and treatment options to a business scenario.
- Identify obligations arising from common regulations and frameworks.
Start here
About 8 minutes of reading, in 10 short parts.
Security is not just technical controls; it is also governance, the policies and processes that decide what an organisation must do, and compliance, proving that it actually does those things. Beginners often underestimate this side of security, but audits, regulations, and executive decisions all run through this layer.
Where you meet it: A security manager has to explain to executives why a particular risk, though technically fixable, will instead be accepted for now because the cost of fixing it exceeds the realistic financial impact of it occurring.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Governance is like the rulebook and decision-making structure of an organisation: who is allowed to approve what, what standards must be followed, and who is accountable if something goes wrong. Compliance is proving, often to an outside party like an auditor or regulator, that the organisation is actually following its own rulebook and any external laws or standards that apply to it.
Risk management is the practical discipline of deciding what to do about a known danger: you can fix it (mitigate), pay someone else to take on the financial consequence (transfer, like insurance), stop doing the risky activity altogether (avoid), or knowingly accept the danger because fixing it costs more than the danger itself (accept). None of these choices is automatically wrong; the mistake is making the choice without actually understanding the risk first.
Key ideas
If you remember nothing else from this topic, remember these.
- Risk management involves identifying, assessing, and responding to risk through avoidance, transference, mitigation, or acceptance, chosen based on cost versus impact.
- Qualitative risk assessment uses descriptive ratings like high, medium, and low, while quantitative risk assessment calculates numeric values such as single loss expectancy and annualized loss expectancy.
- Regulatory and industry frameworks, such as GDPR, HIPAA, and PCI DSS, impose specific, legally or contractually binding requirements depending on the data and industry involved.
- Policies, standards, and procedures form a hierarchy: policies state intent and requirements, standards define specific technical baselines, and procedures give step-by-step instructions to meet them.
- Third-party and vendor risk management extends an organization's risk exposure to its supply chain, since a vendor's weak security can become the organization's incident.
- Business continuity and disaster recovery planning define recovery time objective and recovery point objective targets that drive actual technical backup and failover design decisions.
Assessing risk after discovering an unencrypted customer database backup
A worked example, step by step.
A routine audit discovers that nightly database backups containing customer payment data have been stored unencrypted on a file share for the past year.
- 01Identify the riskDocument the exposure: unencrypted backups containing payment card data accessible to anyone with file share access.
- 02Determine applicable compliance requirementsConfirm PCI DSS applies because payment card data is involved, which explicitly requires encryption of stored cardholder data.
- 03Perform a qualitative assessmentRate the likelihood of exploitation as medium, since access is restricted to internal staff, but rate the impact as high given the regulatory and reputational consequences of a breach.
- 04Perform a quantitative estimateEstimate a single loss expectancy for a breach event and multiply by an estimated annual rate of occurrence to calculate an annualized loss expectancy that justifies remediation cost.
- 05Choose a risk responseSelect mitigation, encrypting the backups going forward, rather than acceptance, given the clear compliance obligation and material impact.
- 06Update policy and standardsRevise the data protection standard to explicitly require encryption at rest for any backup containing cardholder data, closing the gap that allowed this oversight.
- 07Assess third-party exposureConfirm whether any backup vendor or cloud storage provider also has access to the unencrypted files, extending the review to third-party risk.
- 08Report and documentDocument the finding, remediation, and updated standard for the compliance record, and determine whether breach notification obligations apply given the year-long exposure window.
Outcome: The unencrypted backup was identified as a PCI DSS violation, formally risk-assessed both qualitatively and quantitatively, and remediated through encryption and updated standards rather than simply accepted.
Risk and compliance terminology
Worth keeping at hand while you work.
- Risk avoidance
- Eliminating the activity that creates the risk entirely
- Risk transference
- Shifting risk to a third party, such as through insurance
- Risk mitigation
- Reducing risk likelihood or impact through controls
- Risk acceptance
- Formally choosing to accept a risk without further action
- SLE (Single Loss Expectancy)
- Expected monetary loss from a single occurrence of a risk event
- ARO (Annualized Rate of Occurrence)
- Estimated frequency of a risk event per year
- ALE (Annualized Loss Expectancy)
- SLE multiplied by ARO, the expected yearly loss
- GDPR
- EU regulation governing personal data protection and privacy
- HIPAA
- US regulation governing protected health information
- PCI DSS
- Industry standard governing payment card data security
- RTO (Recovery Time Objective)
- Maximum acceptable time to restore a system after disruption
- RPO (Recovery Point Objective)
- Maximum acceptable amount of data loss measured in time
- Third-party risk management
- Assessing and managing risk introduced by vendors and partners
Common misunderstandings
What most beginners get wrong here.
Accepting a risk means ignoring it and doing nothing at all.
Risk acceptance is a formal, documented decision made after evaluating the risk, not an oversight; it acknowledges the risk and consciously chooses not to apply further controls.
Compliance with a framework like PCI DSS guarantees an organization is fully secure.
Compliance establishes a required baseline but does not guarantee security against all threats; organizations can be compliant and still suffer a breach from an uncovered gap.
Qualitative and quantitative risk assessments produce the same kind of result.
Qualitative assessment produces descriptive ratings like high or low, while quantitative assessment produces specific monetary figures like ALE, and the two serve different decision-making purposes.
RTO and RPO measure the same thing.
RTO measures how quickly a system must be restored after an outage, while RPO measures how much data loss, measured in time, is acceptable; they address different aspects of recovery.
Third-party risk only matters if the vendor has direct access to production systems.
A vendor holding sensitive data or performing critical services can introduce significant risk even without direct system access, since a breach on their end can still expose the organization's data.
Exam traps
How the question writers try to catch you out.
- Security+ frequently asks you to calculate ALE from given SLE and ARO figures, requiring straightforward multiplication under time pressure.
- Expect scenario questions asking you to choose the correct risk response, avoidance, transference, mitigation, or acceptance, based on the described action taken.
- Questions distinguishing GDPR, HIPAA, and PCI DSS test whether you can match the regulation to the correct data type and jurisdiction.
- RTO versus RPO questions are commonly confused; RTO is about time to restore service, RPO is about acceptable data loss window.
- Policy hierarchy questions test whether you know that a standard defines specific technical requirements while a procedure gives step-by-step execution instructions.
- Third-party risk questions often expect vendor risk assessments and contractual security requirements as the correct control, not merely trusting the vendor's reputation.
Check yourself
Answer in your head first, then reveal. This is not scored.
If SLE is 50,000 dollars and ARO is 0.5, what is the ALE?
What distinguishes risk mitigation from risk acceptance?
Which regulation would primarily apply to a healthcare provider handling patient records?
What does RPO define in a disaster recovery plan?
In the policy hierarchy, what is the role of a standard compared to a policy?
Why is compliance with a framework not the same as being fully secure?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
Governance defines who decides, policies state intent, standards set mandatory requirements, and procedures give repeatable steps. Risk management identifies, analyses, and treats risk by mitigating, transferring, avoiding, or accepting it. Compliance obligations arise from regulations such as GDPR or HIPAA and frameworks such as ISO 27001, NIST CSF, and CIS Controls.
Why It Matters
Auditors, customers, and insurers ask for evidence, not opinions. Understanding governance turns 'we should patch faster' into a measurable standard with an owner, a target, and reporting.
How It Works
- Risks are identified and rated, then assigned an owner and treatment decision.
- Standards make policy measurable, and procedures make standards repeatable.
- Evidence such as logs, tickets, and reports demonstrates operation over time.
Where You See It
- Audits, vendor security questionnaires, insurance renewals, board reporting, and incident reviews.
Key Terms
- Policy
- A management statement of required intent.
- Control objective
- The outcome a control is meant to achieve.
- Risk register
- The recorded set of identified risks, owners, and treatments.
- SLA
- A committed service level between provider and consumer.
- Audit evidence
- Records proving a control operated as described.
Examples
- A patching standard states critical vulnerabilities are remediated within 14 days, with monthly reporting.
- Cyber insurance often requires demonstrable MFA and tested backups before paying claims.
Common Problems
- Policies nobody reads
- Unowned risks
- Evidence collected only before audits
- Untested recovery plans
How It Fails
- Controls described in policy but not operated fail at audit and during incidents.
- Unowned risks are never treated and resurface after a loss.
- Recovery plans that were never tested fail on the day they are needed.
How to Troubleshoot
- When a control fails, check whether it was defined, owned, and monitored.
- Compare documented procedure with what operators actually do.
- Trace an audit finding to the missing evidence rather than the missing intent.
Practical Knowledge
- Automate evidence generation so compliance is a by-product of operations.
- Test recovery and incident procedures at least annually with a written outcome.
Exam Coverage
- Policies, standards, and procedures
- Risk assessment and treatment
- Regulations, frameworks, and audits
Interview Questions
- What is the difference between a policy and a standard?
- How would you evidence that patching actually happens?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Write a one-page standard for a control you already operate.
- 02Map three of your technical controls to CIS Controls or NIST CSF functions.