Security+ Governance, Risk Management, and Business Impact Analysis

Introduction

This lesson opens Domain 5, Security Program Management and Oversight (20% of SY0-701). It covers objective 5.1, summarizing elements of effective security governance, and objective 5.2, explaining the elements of the risk management process. Security+ governance and risk management connect technical controls to decisions about what to protect, who is accountable, which rules apply, and how much risk the organization will accept. The exam rewards candidates who think like a manager: link controls to business impact, choose a sensible treatment for a risk, and know the document or role responsible for each decision.

After this lesson you will be able to describe the governance document hierarchy, assign responsibilities, calculate quantitative risk values, build and read a risk register, and select among risk treatments.

Learning objectives

After this lesson you will be able to:

• Explain guidelines, policies, standards, and procedures and how they relate.
• Describe external considerations (regulatory, legal, industry, local/regional, national, global) and governance structures such as boards and committees.
• Define roles: data owner, controller, processor, custodian or steward, and subject.
• Distinguish risk identification, assessment, analysis, register, tolerance, appetite, and reporting.
• Calculate SLE, ARO, and ALE and use them to compare control cost with loss.
• Choose among risk avoidance, mitigation, transfer, acceptance, and exemption or exception.
• Explain business impact analysis metrics: RTO, RPO, MTTR, and MTBF.

1. Governance and the document hierarchy

Governance is the system of direction and oversight that ensures security supports business goals. Boards, executive teams, and committees set direction; managers implement it; auditors verify it.

Think of it as a pyramid: policy says what and why, standards say what level, procedures say how, and guidelines suggest good practice. Common policy types you should recognize are:

• Acceptable use policy (AUP): what users may and may not do with company resources.
• Information security policy: overall security direction.
• Business continuity and disaster recovery policies: keep and restore operations.
• Incident response policy: authority and process for incidents.
• Software development life cycle (SDLC) policy: secure development requirements.
• Change management policy: controlled changes (from earlier lessons).
• Access control, password, remote access, and data handling or retention policies.
• Onboarding and offboarding policies: align with joiner-mover-leaver processes.

Playbooks are scenario procedures; monitoring and revision ensure documents stay current. Policies are reviewed on a schedule and after major incidents, legal changes, or business changes.

External considerations

Governance reflects obligations from outside the organization: regulatory (laws such as GDPR, HIPAA, GLBA, SOX), legal (contracts, liability), industry (PCI DSS for card data), geography (local, regional, national, global rules including data residency and cross-border transfer). A multinational must identify the rules applicable to each processing activity and location. Obligations can differ or conflict; a blanket “strictest rule everywhere” approach does not resolve jurisdiction, transfer, or contractual requirements.

Centralized and decentralized governance

Centralized governance has one body set rules for all units, giving consistency. Decentralized governance lets business units or regions tailor decisions, giving flexibility but risking inconsistency. Many organizations combine them: central policy, local implementation.

2. Roles and responsibilities

Remember the difference: the owner decides, the custodian executes, the controller decides why and how personal data is processed, and the processor follows the controller's instructions.

Example 1: a cloud payroll vendor

A company (controller) uses a cloud payroll provider (processor). The company's finance director is the data owner of payroll data and approves who sees it. The provider's operations team acts as custodians on the provider side. A contract must define what the processor may do, how it protects data, and how it reports breaches. If the processor starts using the data for its own marketing, it has overstepped its role and may become a controller with legal consequences.

Apply these roles to identity provisioning and access reviews so approval and implementation responsibilities remain clear.

3. Risk identification and assessment

Risk is the potential for loss: a function of threat, vulnerability, and the impact if exploited. The risk management process is a cycle: identify, assess, analyze, treat, monitor, and report.

• Risk identification: find assets, threats, and vulnerabilities, using inventories, scans, threat intelligence, incident history, and workshops.
• Risk assessment: evaluate likelihood and impact, either one-time, ad hoc, recurring, or continuous.
• Risk analysis: qualitative or quantitative scoring.

Qualitative versus quantitative

Qualitative analysis uses categories such as low, medium, high, and a heat map or matrix. It is quick and good for ranking but subjective. Quantitative analysis uses numbers, usually money and frequency:

• Asset value (AV): worth of the asset.
• Exposure factor (EF): percentage of the asset lost in one event.
• Single loss expectancy (SLE) = AV × EF.
• Annualized rate of occurrence (ARO): estimated mean event frequency per year, not a promise that events occur at regular intervals.
• Annualized loss expectancy (ALE) = SLE × ARO.

Worked example: is the control worth it?

Scenario. A web store's order database is worth $2,000,000 (AV). A successful ransomware attack would destroy 25% of its value in lost sales and recovery (EF = 0.25). The business estimates one such attack every four years (ARO = 0.25). The simplified model assumes a proposed backup/EDR program costs $45,000 per year and reduces EF to 5% while holding ARO constant. These are scenario estimates, not measured control guarantees; in practice controls may affect both frequency and impact.

Steps.

1. Current SLE = $2,000,000 × 0.25 = $500,000.
2. Current ALE = $500,000 × 0.25 = $125,000 per year.
3. New SLE = $2,000,000 × 0.05 = $100,000. New ALE = $100,000 × 0.25 = $25,000.
4. Risk reduction = $125,000 − $25,000 = $100,000 per year.
5. Net benefit = $100,000 − $45,000 cost = $55,000 per year. Under these assumptions, the modeled annual benefit exceeds annual cost.

Why other conclusions are weaker. Looking only at the $45,000 cost suggests the program is expensive but ignores the $100,000 reduction. Rejecting it because the attack is "unlikely" ignores that the expected annual loss is still $125,000. Expected loss is one decision input. Consider uncertainty, extreme losses, safety, obligations, dependencies, and costs over the control’s useful life. A control can be justified even when its cost exceeds a single-year point estimate of loss reduction.

Risk register

A risk register lists identified risks with: description, asset, owner, likelihood, impact, inherent score, existing controls, treatment decision, residual score, due dates, and status. The risk owner is accountable for managing a risk. Registers are reviewed regularly and reported to leadership through dashboards and key risk indicators (KRIs), which signal increasing risk exposure, such as the number of unpatched critical systems.

Inherent, residual, and tolerance

• Inherent risk: risk under the assessment’s stated pre-control assumptions. Document which controls, if any, are included in that baseline.
• Residual risk: risk remaining after controls.
• Risk appetite: the amount and type of risk the organization is willing to pursue to meet objectives; it is strategic and set by leadership. Appetite may be expansionary, conservative, or neutral.
• Risk tolerance: the acceptable variation around the appetite for a specific risk, such as "no more than four hours of downtime."
• Risk threshold: the point at which action is required.

Organizations may be risk-averse (low appetite) or risk-seeking (high appetite), but appetite can vary by risk category within the same organization; a label such as “risk-seeking” is not permission to accept every type of exposure.

4. Risk treatment

After analysis, management chooses how to respond:

Transfer is limited by contract terms, deductibles, exclusions, and counterparty capability. It does not remove applicable accountability: a company that outsources processing still owes duties to customers and regulators. Acceptance must be documented, approved by someone with authority at the right level, reviewed periodically, and should not be a way to ignore a problem. An exception commonly records a temporary approved deviation, while exemption may describe approved non-applicability or a different waiver category. Organizations define these terms differently. Record justification, authority, duration/review, and any compensating controls. An internal approval cannot waive an applicable law or external requirement.

Example 2: legacy medical device

A hospital's MRI controller runs an unsupported operating system that cannot be patched without voiding the manufacturer's warranty. The risk cannot be avoided without giving up the machine. The security team mitigates: isolate it on its own VLAN, allow only the imaging server to connect, disable unused ports, and monitor it. The remaining residual risk is documented in the register, the CIO signs a time-limited exception, and the risk is reviewed in six months or when the vendor offers an upgrade.

5. Business impact analysis

A business impact analysis (BIA) identifies critical business functions and the effect of their disruption. It supports risk analysis and continuity planning. Key metrics:

A BIA also identifies mission-essential functions, single points of failure, dependencies, and recovery priorities. If an order system has an RPO of 15 minutes, nightly backups cannot meet it; replication or frequent log shipping is needed.

Example 3: setting recovery objectives

An airline's check-in system generates $400,000 per hour in revenue and cannot lose bookings. The BIA sets an RTO of 30 minutes and an RPO of near zero. That can justify a highly available design with replication appropriate to the acknowledged-write loss target. Active-active sites and synchronous replication are possible components, but test data consistency, shared dependencies, latency, failover, and capacity; those labels alone do not prove the objectives are met. A staff-wiki, in contrast, is given an RTO of three days and an RPO of 24 hours, justifying cheap nightly backups.

Translate the targets into backup, resilience, and disaster recovery designs and validate them with restore tests.

6. Reporting and communicating risk

Risk information flows upward and across: risk registers feed dashboards for executives, KRIs track trends, and risk committees review exceptions. Risk reporting should be concise, tied to business impact and decisions needed. Use consistent scales so scores compare across departments, and avoid reporting only technical details, such as the number of vulnerabilities, without business context.

Feed vulnerability assessment and remediation evidence into the register rather than reporting raw finding counts alone.

7. Comparison: which term fits?

8. Common pitfalls

• Mixing up policy, standard, procedure, and guideline.
• Confusing RTO with RPO: RTO is time to restore, RPO is data loss measured in time.
• Treating transfer as removing responsibility.
• Accepting a risk without documented approval or a review date.
• Calculating ALE using the whole asset value when the exposure factor is less than 100%.
• Confusing risk appetite (organization-wide, strategic) with risk tolerance (specific, acceptable variation).
• Leaving the risk register stale or without owners.
• Calling every deviation an exception when it is a permanent exemption, or the reverse.

9. Exam tips

• Exam tip: Memorize SLE = AV × EF, ALE = SLE × ARO. Questions often give three of the four numbers.
• Exam tip: "Stop doing the activity" is avoid; "buy insurance" is transfer; "implement controls" is mitigate; "knowingly live with it" is accept.
• Exam tip: Data owner decides and is accountable; custodian implements.
• Exam tip: A requirement that must be followed and is measurable is a standard; step-by-step instructions are a procedure.
• Exam tip: In scenario questions, the BIA identifies what is critical first; recovery objectives derive from it.
• Exam tip: Residual risk after treatment must still fit within appetite and tolerance; if not, treat further.

10. Mini case study

Situation. A regional bank's customer-loan database is valued at $8,000,000. Analysts estimate a data breach would cost 15% of that in fines, notification, and lost business. They expect one such breach every five years. A proposed data loss prevention and encryption project costs $90,000 per year and would cut the exposure factor to 5%. Separately, the bank's loan application portal has an RTO of two hours and an RPO of 10 minutes, but current backups run every four hours to a site that takes eight hours to restore.

Questions.

1. Calculate the current ALE and the ALE after the project. Is it justified?
2. Which risk treatment is the project?
3. Does the portal meet its objectives? What should change?
4. What should be recorded in the register?

Commented solution.

1. Current SLE = $8,000,000 × 0.15 = $1,200,000; ARO = 0.2, so ALE = $240,000. After the project SLE = $8,000,000 × 0.05 = $400,000, ALE = $80,000. Reduction = $160,000 per year against a $90,000 cost, a net benefit of $70,000, so the project is justified financially.
2. Mitigation, because it reduces impact using controls.
3. No. Backups every four hours imply up to four hours of data loss against an RPO of 10 minutes, and eight hours to restore against an RTO of two hours. The bank needs a recovery design whose latest usable point is no older than 10 minutes, including completion delay and replication lag, and whose tested end-to-end recovery fits two hours. Replication/log shipping and a suitably provisioned standby are options; retain protected historical backups too.
4. Record both risks with descriptions, owners (the loan business owner and the CISO), inherent and residual scores, treatment decisions, the project funding, target dates, KRIs such as backup success rate, and the date for the next review. Executives should see the net benefit and the residual risk in business terms.

Key terms

• Policy / standard / procedure / guideline: the governance document hierarchy.
• Data owner, controller, processor, custodian: roles for data accountability.
• Risk appetite / tolerance: strategic willingness and acceptable variation.
• Inherent / residual risk: before and after controls.
• SLE, ARO, ALE: single loss, annual rate, annual loss expectancy.
• Risk register: tracked list of risks, owners, and treatments.
• KRI: key risk indicator.
• Avoid, mitigate, transfer, accept: risk treatment strategies.
• Exception / exemption: documented deviation from policy.
• BIA: business impact analysis.
• RTO / RPO / MTTR / MTBF: recovery and reliability metrics.

Summary checklist

• I can distinguish policies, standards, procedures, and guidelines and name common policy types.
• I can assign the roles of data owner, controller, processor, custodian, and subject.
• I can compute SLE, ARO, and ALE and judge whether a control is cost-effective.
• I can describe a risk register, inherent and residual risk, appetite, and tolerance.
• I can choose between avoid, mitigate, transfer, and accept, and explain exceptions and exemptions.
• I can explain a BIA and RTO, RPO, MTTR, and MTBF.
• I can communicate risk with KRIs and consistent scales.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 5.1–5.2.

• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments: https://csrc.nist.gov/pubs/sp/800/30/r1/final (opens in a new tab)

• NIST SP 800-39, Managing Information Security Risk: https://csrc.nist.gov/pubs/sp/800/39/final (opens in a new tab)

• NIST Risk Management Framework: https://csrc.nist.gov/projects/risk-management/about-rmf (opens in a new tab)

• ISO/IEC 27005 overview: https://www.iso.org/standard/80585.html (opens in a new tab)

• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (opens in a new tab)

• NIST IR 8286B, updated 2025: prioritizing enterprise cybersecurity risk (opens in a new tab)