Chapter 5: Security Program Management and Oversight
What you will learn
By the end of this chapter, you will be able to:
- Explain the governance document hierarchy — policies, standards, procedures, and guidelines — and who is responsible for each.
- Describe the key governance roles: chief information security officer (CISO), data owner, data custodian, and data protection officer (DPO).
- Walk through the change management process and explain why unmanaged change is a security risk.
- Perform a risk assessment using both qualitative and quantitative methods, including SLE, ARO, EF, and ALE calculations.
- Read and build a risk register, risk matrix, and heat map, and choose an appropriate risk response: accept, mitigate, transfer, or avoid.
- Distinguish risk appetite from risk tolerance.
- Explain a business impact analysis (BIA) and use RTO, RPO, MTTR, and MTBF correctly.
- Assess third-party risk across the vendor lifecycle, and match business agreements — MSA, SOW, SLA, MOU, NDA, BPA — to their purposes.
- Describe the scope of GDPR, PCI DSS, HIPAA, SOX, and FISMA, plus core privacy concepts: data subjects, controllers, processors, and breach notification.
- Compare internal and external audits, attestation, and penetration tests as assessment types.
- Describe the elements of an effective security awareness program, including phishing simulations and a reporting culture.
- Select and interpret governance metrics such as MTTR trend, patch latency, and phishing click rate.
Reading
5.1 Governance: steering the security program
Security tools do not run a security program — people, decisions, and documents do. Governance is the framework of rules, roles, and processes that directs how an organization protects its information. It answers three questions: What must we protect and why? Who is accountable? How do we prove we are doing it? Everything in this chapter flows from governance: risk management prioritizes the work, compliance proves the work to outsiders, and metrics show whether the work is succeeding.
The governance document hierarchy
Organizations document their expectations in a hierarchy. Each level is more specific than the one above it:
| Document | Binding? | Purpose | Example |
|---|---|---|---|
| --- | --- | --- | --- |
| Policy | Mandatory | High-level statement of intent and rules approved by leadership | "All company data must be classified and protected according to its sensitivity." |
| Standard | Mandatory | Specific, measurable requirements that support a policy | "Passwords must be at least 14 characters; AES-256 is required for data at rest." |
| Procedure | Mandatory | Step-by-step instructions for performing a task | "To provision a new user: 1. Verify the approved ticket… 2. Create the account…" |
| Guideline | Optional (recommended) | Advice and best practice that staff may follow | "Consider using a password manager with separate vaults for work and personal accounts." |
A useful way to remember the difference: a policy says what and why, a standard says the exact requirements, a procedure says how, step by step, and a guideline says here is a good way, if it helps. Policies are deliberately technology-neutral and stable — a good acceptable use policy survives several laptop refresh cycles. Standards and procedures change more often because they name real products and settings.
Real-world example: a hospital's policy states that patient records must be accessible only to staff with a treatment relationship. A standard then requires unique user IDs, multi-factor authentication (MFA) for remote access, and automatic logoff after 10 minutes. Procedures tell the help desk exactly how to reset a clinician's password. A guideline suggests clinicians use badge-tap workstations where available. If an auditor finds shared accounts, the finding traces back up the chain: staff broke the standard, which means the policy failed.
If a question describes a document that is recommended but not required, it is a guideline. If it is mandatory and step-by-step, it is a procedure. CompTIA loves this distinction.
Governance roles and accountability
Governance only works when accountability is named. Four roles appear constantly on the SY0-701 exam:
- Chief information security officer (CISO): The senior executive accountable for the organization's information security program — strategy, budget, risk reporting to the board. The CISO owns the program, not every individual control.
- Data owner: A business leader (often a department head or executive) accountable for a specific set of data — deciding its classification, who may access it, and how long it is kept. The owner of payroll data is usually an HR or finance executive, not an IT administrator, because the business understands the data's value and legal duties.
- Data custodian: The person or team that implements the owner's decisions day to day — typically IT staff who configure access controls, run backups, apply encryption, and monitor the systems holding the data. Custodians protect the data; owners decide how it should be protected.
- Data protection officer (DPO): A privacy role, formally required by the GDPR for many organizations, that oversees how personal data is processed, advises on privacy law, and acts as the contact point for regulators and data subjects. The DPO must be able to work independently — a DPO should not also be the person deciding how data is used for marketing, because that would be a conflict of interest.
"Accountable for classifying data and approving access" = data owner. "Implements controls, maintains systems, performs backups" = data custodian. When in doubt, accountability sits with the owner; hands-on work sits with the custodian.
Change management: controlling how things change
Most outages and many breaches trace back to a change somebody made: a firewall rule edited at midnight, an unpatched "temporary" server, a debug setting left on in production. Change management is the formal process that makes changes visible, reviewed, and reversible. A typical process looks like this:
- Request: The change is documented — what, why, what systems it touches.
- Impact assessment: Risks are evaluated, including security impact and what could break.
- Approval: A manager or change advisory board (CAB) approves or rejects the change. Emergency changes have a faster path but are reviewed afterwards.
- Testing: The change is validated in a test environment where practical.
- Implementation: The change is made in an approved window, with a documented backout (rollback) plan if it fails.
- Documentation and review: The change, its results, and any incidents are recorded; configuration records are updated.
Why does security care so much? Because change management gives you an audit trail (who changed what, when, and with whose approval), prevents unauthorized changes (a classic insider-threat and attacker technique is quietly modifying configurations), and forces a security review before a risky change reaches production. An organization with mature change management will catch "we're opening port 3389 to the internet for a vendor demo" at step 2 — not during the incident response three weeks later.
If a scenario describes repeated outages or vulnerabilities appearing after undocumented, unapproved modifications, the fix the exam wants is a formal change management process — not more monitoring tools.
5.2 Risk management: deciding what to worry about first
Risk is the potential for a threat to exploit a vulnerability and cause harm to an asset. No organization can fix everything, so risk management is the discipline of finding risks, sizing them, and spending limited money where it reduces harm the most.
The risk management cycle
- Risk identification: Inventory assets (servers, data, processes, people), then identify the threats and vulnerabilities that could harm them. Techniques include asset inventories, threat intelligence, vulnerability scans, workshops, and reviewing incident history. You cannot assess a risk you have not identified — forgotten assets ("shadow IT") are a classic blind spot.
- Risk assessment (analysis): Estimate how likely each risk is and how bad the impact would be, using qualitative or quantitative methods (below).
- Risk response: Choose a treatment for each risk (Section 5.2.3).
- Monitoring and review: Risks change — new threats appear, controls decay, the business launches new products — so the cycle repeats continuously.
Qualitative vs. quantitative assessment
| Aspect | Qualitative | Quantitative |
|---|---|---|
| --- | --- | --- |
| Basis | Judgment, experience, expert opinion | Historical data and monetary values |
| Scale | High / Medium / Low, or 1–5 ratings | Dollars (or other numbers): SLE, ALE |
| Output | Prioritized list, heat map position | Annual expected loss per risk |
| Data needed | Little — works with no loss history | Needs asset values, frequencies, loss data |
| Speed | Fast; can assess dozens of risks in a workshop | Slow; data collection is expensive |
| Best for | Quick prioritization, new risks, board communication | Budget decisions, justifying a control's cost |
| Weakness | Subjective; two teams may rate differently | False precision; garbage data in, garbage numbers out |
Qualitative assessment rates likelihood and impact on scales and multiplies or plots them. It is fast and works even when an organization has never tracked losses. Quantitative assessment attaches numbers — ideally money — to risk so it can be compared directly with the cost of controls. Many mature programs use both: qualitative to triage everything, quantitative to analyze the top risks in depth.
The quantitative math: AV, EF, SLE, ARO, ALE
Four values drive the calculation:
- Asset value (AV): What the asset is worth — replacement cost, rebuild effort, and the value of the data or service it provides.
- Exposure factor (EF): The percentage of the asset's value lost if the event happens once (0–100%).
- Single loss expectancy (SLE): The cost of one occurrence: SLE = AV × EF.
- Annualized rate of occurrence (ARO): How many times the event is expected per year. Once every four years = 0.25; twice a year = 2.
- Annualized loss expectancy (ALE): The expected yearly cost: ALE = SLE × ARO.
Worked example. An online retailer runs a database server environment valued at $200,000 (hardware, rebuild labor, and the value of the operational data). A ransomware event is estimated to destroy or lock up 60% of that value before recovery (EF = 0.60), and intelligence plus incident history suggest it happens about once every four years (ARO = 0.25).
- SLE = AV × EF = $200,000 × 0.60 = $120,000 per incident.
- ALE = SLE × ARO = $120,000 × 0.25 = $30,000 per year.
Now evaluate a control: immutable backups plus endpoint detection and response (EDR), costing $12,000 per year, expected to cut the exposure factor to 10% (most data recoverable, brief outage).
- New SLE = $200,000 × 0.10 = $20,000.
- New ALE = $20,000 × 0.25 = $5,000 per year.
- Risk reduction = $30,000 − $5,000 = $25,000 per year, for a $12,000 cost.
The control pays for itself — a clear, defensible budget argument. This cost-versus-ALE comparison is the single most common reason to do quantitative analysis.
Memorize the chain: SLE = AV × EF, then ALE = SLE × ARO. If a question gives you an asset value, a percentage loss, and "once every X years," it wants ALE. Convert "every 4 years" to ARO 0.25 before multiplying.
The risk register, matrix, and heat map
A risk register is the living document (or system) that records each risk: its description, owner, likelihood, impact, current score, chosen response, and review date. It is where assessment results become accountable action — a risk with no owner is a risk nobody is managing.
A risk matrix plots likelihood against impact on a grid (for example, 5 × 5). Multiplying the two ratings gives a risk score used for ranking. A heat map is the visual version of that matrix, colored green (low) through yellow/amber to red (high), so executives can see at a glance where the dangerous combinations — high likelihood and high impact — cluster in the top-right corner.
Example: a risk rated likelihood 4, impact 5 scores 20 and sits in the red zone. A risk rated likelihood 5, impact 1 scores 5 — annoying but tolerable. Scores let a team sort the register and fund work from the top down.
Risk responses
Once a risk is assessed, there are four classic responses (treatments):
| Response | Meaning | Example |
|---|---|---|
| --- | --- | --- |
| Accept | Live with the risk because the impact is low or treatment costs more than the risk | Accepting that the office coffeemaker might break; accepting a small, documented risk to launch on time |
| Mitigate | Reduce likelihood or impact with controls | Adding MFA to reduce account-takeover risk |
| Transfer | Share the financial impact with a third party | Buying cyber insurance; outsourcing payment processing to a PCI-compliant provider |
| Avoid | Stop the activity that creates the risk | Deciding not to store card numbers at all; cancelling a launch in a market where the risk is unacceptable |
Notes the exam cares about: transferring risk moves the financial impact, never the accountability — if your vendor loses your customers' data, your customers still blame you. Acceptance of a risk that exceeds normal thresholds is documented as an exception (or exemption) with an owner and an expiry date, and requires approval at the right level. Doing nothing without a decision is not acceptance — it is negligence with extra steps.
Risk appetite and risk tolerance
Risk appetite is the broad amount and type of risk an organization is willing to pursue or retain in pursuit of its goals — usually set by the board. A startup might have a high appetite ("move fast, accept product risk"), while a hospital's appetite for patient-safety risk is near zero. Risk tolerance is the acceptable variation around specific objectives — the practical, measurable boundary: "we tolerate up to 4 hours of downtime for the email system, but no more than 15 minutes for the payment platform." Appetite is the philosophy; tolerance is the number you measure against. When a risk exceeds tolerance, it escalates — it needs treatment or a formal exception.
Appetite = the overall level of risk the organization is willing to take (strategic, board-level). Tolerance = the acceptable deviation for a specific target or system (operational, measurable).
5.3 Business impact analysis: knowing what matters most
A business impact analysis (BIA) identifies the organization's critical functions and quantifies what happens when they fail — financially, operationally, legally, and reputationally — over time. Its output drives both the risk register (impact estimates) and disaster recovery planning (recovery priorities).
Mission-essential functions
The BIA starts by identifying mission-essential functions: the processes the organization cannot survive without, or cannot legally stop. For a bank, that is processing transactions; for a hospital, patient care systems; for an online retailer, the storefront and payment flow. The marketing blog, however beloved, is not mission-essential. For each function, the BIA documents its dependencies (systems, data, people, vendors), the impact of an outage at 1 hour, 1 day, and 1 week, and the maximum downtime the business can tolerate before the damage becomes unacceptable.
The four recovery metrics
| Metric | What it measures | In plain words | Example |
|---|---|---|---|
| --- | --- | --- | --- |
| RTO — recovery time objective | Maximum acceptable time to restore a system or function after an incident | "We must be back up within…" | RTO of 4 hours for the payment platform |
| RPO — recovery point objective | Maximum acceptable data loss, measured as time | "We can afford to lose at most…" | RPO of 15 minutes → backups/replication at least every 15 minutes |
| MTTR — mean time to repair (recover) | Average time to restore a failed system, measured from real incidents | "On average, fixing this takes…" | MTTR of 2.5 hours across the last 10 outages |
| MTBF — mean time between failures | Average time a system runs before failing | "This fails about every…" | MTBF of 4,000 hours for a disk array |
Two distinctions the exam tests relentlessly. First, RTO is about time to restore service; RPO is about data loss — and RPO is what dictates backup frequency. If your RPO is 1 hour, nightly backups are a finding waiting to happen. Second, RTO and RPO are targets you set in advance (objectives); MTTR and MTBF are measurements from reality. Comparing them tells you whether you can actually meet your objectives: if the payment platform's RTO is 4 hours but its measured MTTR is 9 hours, the plan fails on paper before any disaster occurs — the BIA has just found a gap to fix.
Aligning with disaster recovery
The BIA hands disaster recovery (DR) its priorities: recover mission-essential functions first, in dependency order, to the RTO/RPO the business approved. DR strategies — hot, warm, and cold sites; cloud failover; backup restoration order — are chosen and funded based on BIA numbers, not on IT's preferences. When the CFO asks why the hot site costs so much, the answer is the BIA: "You approved a 4-hour RTO and a 15-minute RPO for payments; this is what meeting them costs." The BIA is also refreshed when the business changes — a new product line or acquisition makes last year's analysis quietly wrong.
"How much data can we lose?" → RPO. "How fast must we be back?" → RTO. "How long does repair usually take?" → MTTR. "How often does it break?" → MTBF.
5.4 Third-party risk: your vendors' security is your security
Organizations run on vendors: cloud platforms, SaaS tools, payment processors, managed service providers, cleaning crews with building access. Every vendor with your data or a connection into your network extends your attack surface. Third-party risk management (TPRM) assesses that risk before signing, contracts for the right protections, and keeps watching after the ink dries.
Assessing vendors before and during the relationship
The lifecycle typically runs:
- Risk tiering: Classify the vendor by the sensitivity of data they will touch and the criticality of their service. A vendor hosting patient records gets a deep review; the sandwich shop does not. Tiering focuses effort where the risk actually is.
- Assessment: Send a security questionnaire (covering access control, encryption, incident response, patching, sub-processors, and compliance certifications) and review evidence — independent audit reports such as SOC 2, penetration test summaries, and certifications. Site visits happen for the most critical vendors. A questionnaire is the vendor's claim; evidence is how you check it.
- Contracting: Put security requirements in writing (next section), including a right-to-audit clause — the contractual right to inspect the vendor's controls, or receive independent audit results, on an agreed cadence. Without it, "trust us" is all you have.
- Onboarding and integration: Provision access with least privilege, unique accounts, and MFA. A vendor's standing, shared VPN account is a breach waiting for a timestamp.
- Ongoing monitoring: Vendor monitoring continues for the whole relationship — annual reassessments, tracking the vendor's public breaches and financial health, reviewing fresh audit reports, and re-tiering when the service changes. The vendor you assessed in 2023 may have been acquired, outsourced its support, or quietly moved your data to a new region.
- Offboarding: Revoke access, retrieve or certify destruction of your data, and close the accounts. Forgotten vendor access is a recurring cause of real breaches.
The agreement alphabet
Different agreements do different jobs. Matching the document to the purpose is heavily tested:
| Agreement | Full name | Purpose |
|---|---|---|
| --- | --- | --- |
| NDA | Non-disclosure agreement | Binds parties to keep shared information confidential; usually signed before sensitive details are exchanged |
| MSA | Master service agreement | The umbrella contract: general legal and commercial terms governing the whole relationship |
| SOW | Statement of work | Defines a specific engagement under the MSA: tasks, deliverables, timelines, and fees |
| SLA | Service-level agreement | Measurable performance commitments — uptime, response and resolution times — and the remedies or penalties when they are missed |
| MOU | Memorandum of understanding | A non-binding (or lightly binding) statement of intent and shared goals between parties |
| BPA | Business partners agreement | Sets out the terms of an ongoing business partnership — roles, responsibilities, profit/liability sharing between partners |
Working through an example: two companies exploring a partnership sign an NDA before sharing roadmaps, then an MOU to declare they intend to work together. When they commit, lawyers draft an MSA; each project gets a SOW; the hosting provider's uptime promise goes in an SLA (99.9% availability, credits if missed); and the joint venture's operating terms live in a BPA.
Uptime guarantees and penalties = SLA. "We intend to cooperate" (not a hard contract) = MOU. The specific project's deliverables = SOW. Everything else sits under the MSA umbrella.
Supply chain risk
Risk extends beyond your direct vendors to their suppliers — the supply chain. Compromised software updates, tampered hardware, malicious components in open-source libraries, and a vendor's own subcontractors have all been attack vectors. Defenses include requiring vendors to disclose sub-processors, verifying software integrity (hashes, signatures, bills of materials), sourcing hardware from authorized channels, and having an exit plan for critical suppliers. The governing idea: your risk assessment must follow the data and the access, wherever they actually go.
5.5 Compliance and privacy: proving it to the outside world
Compliance means meeting obligations imposed from outside — laws, regulations, industry standards, and contracts — and being able to demonstrate it. Governance decides what the organization should do; compliance is where regulators, customers, and auditors check whether it did.
The major frameworks at scope level
| Framework | Who/what it covers | Core subject |
|---|---|---|
| --- | --- | --- |
| GDPR | Organizations processing personal data of people in the EU/EEA | Privacy rights: lawful basis, consent, data subject rights, breach notification |
| PCI DSS | Any organization that stores, processes, or transmits payment card data | Protecting cardholder data: network security, encryption, access control, testing |
| HIPAA | US healthcare providers, insurers, and their business associates | Privacy and security of protected health information (PHI) |
| SOX | US publicly traded companies | Integrity of financial reporting: internal controls over financial systems and audits |
| FISMA | US federal agencies and their contractors | Federal information security programs and controls (built on NIST guidance) |
You do not need lawyer-level depth for SY0-701 — you need the scope cold: card data → PCI DSS; health data → HIPAA; EU personal data → GDPR; public-company financial reporting → SOX; federal systems → FISMA.
Privacy roles and duties
Privacy law assigns roles based on who decides what happens to personal data:
- Data subject: The individual the data is about — the customer, patient, or employee.
- Data controller: The organization that decides why and how personal data is processed ("we collect customer emails to send receipts"). Controllers carry the primary legal responsibility.
- Data processor: The organization that processes data on behalf of a controller, following its instructions — a payroll SaaS or email platform. Processors have their own duties (security, assisting with breaches) but do not get to repurpose the data.
Privacy comes with operational duties: honor data subject rights (access, correction, deletion), collect only what is needed, and — the one with a clock on it — breach notification. Under the GDPR, a controller that suffers a personal-data breach must notify the supervisory authority within 72 hours of becoming aware of it (unless the breach is unlikely to risk individuals' rights), and notify affected individuals without undue delay when the risk is high. Many other laws impose their own deadlines; the security team's incident process must know them before the incident.
Compliance reporting, internal and external
Compliance reporting happens in both directions. Internal reporting keeps leadership honest: control test results, open findings, remediation deadlines, and risk acceptance sign-offs, usually flowing to the CISO, audit committee, or board. External reporting demonstrates compliance to regulators, card brands, customers, and auditors — filed attestations, regulator submissions, and responses to customer due-diligence questionnaires. The two must never tell different stories; a regulator discovering that internal reports flagged a control as failed while external reports called it compliant is how fines become headlines.
Licensing and agreements in compliance
Compliance also covers using other people's intellectual property legally: tracking software licensing (license counts, open-source license obligations, end-user agreements), verifying that fonts, images, and code libraries are used within their terms, and ensuring contracts with customers and vendors reflect regulatory duties (for example, HIPAA business associate agreements with every vendor touching PHI). An unlicensed-software finding is a compliance failure even though no attacker was involved.
If the scenario involves notifying a regulator about a breach of EU citizens' data, think GDPR and 72 hours. If it involves fines tied to cardholder data exposure, think PCI DSS — enforced through the card brands and acquiring banks, not a government regulator.
5.6 Audits and assessments: checking the work
Governance sets the rules; audits and assessments verify reality against them. They differ in who performs them and how much you can trust the result:
- Internal audits/assessments: Performed by the organization's own audit team (or a team independent of the people running the controls). Cheap, frequent, and close to the business — ideal for continuous improvement and for finding problems before outsiders do. The catch is independence: an internal team reviewing its own company's work faces pressure an outsider does not.
- External audits: Performed by an independent third party — regulators, certification bodies, or audit firms. Slower and more expensive, but the result carries credibility with customers, insurers, and regulators. A SOC 2 report or an ISO 27001 certificate exists precisely because outsiders trust it more than a company's word.
- Attestation: A formal statement by an independent auditor that something is true — for example, an auditor's opinion in a SOC 2 Type II report attesting that controls operated effectively over a period. Attestation is the auditor signing their name to the conclusion; that accountability is the point.
- Penetration tests are a different kind of assessment: authorized, simulated attacks that test whether defenses actually work, rather than whether documents say they should. A compliance audit might confirm a firewall policy exists; a penetration test tries to get past the firewall. Governance uses both — audits check conformance, penetration tests check effectiveness — and both feed findings into the risk register with owners and deadlines. An assessment that produces a report nobody acts on is theater, not governance.
Regulatory examinations sit at the far end of this spectrum: government examiners (for banks, healthcare, federal contractors) can compel evidence and impose penalties. Smart organizations treat internal audits as rehearsals for that day.
Key word "independent" points to an external audit or attestation. Key phrase "our own team verifying controls before the auditors arrive" points to an internal assessment.
5.7 Security awareness: governing the human layer
Technology cannot patch people, but governance can train them. A security awareness program reduces human-driven risk — phishing clicks, weak passwords, tailgating, careless data handling — through continuous education rather than one annual video.
Effective programs include:
- Phishing simulations: Fake phishing emails sent to staff, tracking who clicks, who enters credentials, and — most importantly — who reports. Results drive targeted coaching for repeat clickers and departments with elevated rates. Done well (no public shaming, quick feedback, a short training at the moment of failure), simulations measurably lower click rates over time.
- Training campaigns: Ongoing, role-relevant education — short modules, posters, intranet posts, lunch-and-learns — timed to real threats (tax-season scams for finance staff, invoice fraud for accounts payable). Annual refresher training also keeps the organization compliant with frameworks that mandate it: threats and policies change, so training repeats even for veteran staff.
- A reporting culture: The program's real goal. Staff who spot something must find it easy and safe to report — a one-click report-phish button, a known phone number, and thanks rather than blame when they do. Every employee report is a free sensor for the security team; organizations that punish mistakes teach staff to hide them, and hidden incidents become breaches. This is why simulated phishing is a measurement and education tool, never a disciplinary trap.
- Insider threat awareness: Training staff and managers to recognize warning signs — unusual data downloads, access outside role, disgruntlement combined with new access — and routes to raise concerns. Insider threat programs balance security with privacy and HR involvement; the goal is early help and early detection, not surveillance of everyone.
Awareness is a governance function, not an IT side project: it has an owner, a budget, a schedule, and metrics (next section) reported alongside patch and incident numbers.
5.8 Metrics that matter: proving the program works
Governance runs on evidence, and evidence means metrics — repeated measurements that show direction, not just snapshots. Three habits separate useful metrics from vanity numbers:
- Trend beats snapshot. A single MTTR value says little; MTTR falling from 9 days to 3 days over two quarters says the program is improving. Boards and auditors ask "which way is it moving?"
- Measure outcomes, not activity. "We sent 500 training emails" is activity. "Phishing click rate fell from 18% to 6%" is an outcome.
- Every metric needs an owner and a threshold. When a number crosses the line, someone acts.
Metrics that earn their place on a SY0-701 answer — and on a real dashboard:
- Mean time to remediate (MTTR) trend for vulnerabilities and incidents: is the organization closing exposures faster or slower? A worsening trend with a growing estate tells leadership exactly where to fund.
- Patch latency: The time between a vendor releasing a patch (especially for critical vulnerabilities) and its deployment across the estate — often reported as median days, or "% of critical patches applied within the 14-day SLA." Patch latency is the metric attackers effectively set your deadline with: exploits for critical flaws appear within days of disclosure.
- Phishing click rate (and report rate): The percentage of staff clicking simulated phishes, trended over time, paired with the percentage who reported the message. Click rate falling while report rate rises is the signature of a maturing awareness program — and the report rate arguably matters more, because real incidents are caught by the first employee who speaks up.
- Supporting cast: percentage of systems covered by EDR and MFA, overdue risk exceptions, audit findings past due, vendor reassessments completed on schedule — each maps to a governance process in this chapter.
Metrics close the loop of the entire chapter: governance sets expectations, risk management prioritizes, compliance verifies, and metrics prove — to the board, to auditors, and to yourself — whether any of it is working.
When a question asks which metric shows a program is improving, pick the trend in an outcome — MTTR trend, patch latency, or click-rate trend — over any one-time count or inventory number.
5.9 Bringing it together
Notice how the pieces of this chapter interlock in practice. A hospital's board sets a low risk appetite for anything touching patient safety. That appetite shapes the risk register, where ransomware on clinical systems scores red. The BIA supplies the impact numbers — an RTO of 4 hours and an RPO of 15 minutes for the electronic health record — and those objectives justify the ALE-based business case for immutable backups. The backup platform is a vendor, so third-party risk management tiers it as critical, contracts it under an MSA with an SLA and a right-to-audit clause, and monitors it annually. HIPAA supplies the compliance floor, internal audits rehearse for external scrutiny, and change management makes sure nobody "fixes" the backup network on a Friday night without approval. Awareness training lowers the phishing click rate that feeds the ransomware likelihood score, and the metrics on the CISO's dashboard — MTTR trend, patch latency, click rate — tell the board, quarter after quarter, whether the whole machine is actually working. That is Domain 5 in one paragraph: not paperwork for its own sake, but the management system that makes every technical control in the other four domains deliberate, funded, and provable.
Key terms
| Term | Definition |
|---|---|
| --- | --- |
| Policy | Mandatory, high-level governance document stating leadership's intent and rules |
| Standard | Mandatory, specific measurable requirements that implement a policy |
| Procedure | Mandatory step-by-step instructions for performing a task |
| Guideline | Optional, recommended best practice |
| CISO | Executive accountable for the organization's information security program |
| Data owner | Business leader accountable for a data set's classification, access approvals, and retention |
| Data custodian | Person or team (usually IT) that implements protective controls and handles data day to day |
| Data protection officer (DPO) | Independent privacy role overseeing personal-data processing and regulator/data-subject contact, required by GDPR for many organizations |
| Change management | Formal process for requesting, assessing, approving, testing, implementing, and documenting changes |
| Asset value (AV) | Monetary value of an asset, including replacement and data/service value |
| Exposure factor (EF) | Percentage of an asset's value lost when an incident occurs once |
| Single loss expectancy (SLE) | Cost of one incident: SLE = AV × EF |
| Annualized rate of occurrence (ARO) | Expected frequency of an incident per year |
| Annualized loss expectancy (ALE) | Expected yearly loss: ALE = SLE × ARO |
| Risk register | Living record of identified risks, their owners, scores, responses, and review dates |
| Risk matrix / heat map | Grid plotting likelihood against impact, color-coded to visualize risk levels |
| Risk appetite | The overall amount and type of risk leadership is willing to take in pursuit of objectives |
| Risk tolerance | The measurable, acceptable variation around a specific objective |
| RTO | Recovery time objective — maximum acceptable time to restore a function |
| RPO | Recovery point objective — maximum acceptable data loss, expressed as time |
| MTTR | Mean time to repair/recover — average measured time to restore a failed system |
| MTBF | Mean time between failures — average measured time a system operates before failing |
| Mission-essential function | A process the organization cannot survive without or is legally required to perform |
| Right-to-audit clause | Contract term allowing a customer to inspect a vendor's controls or receive independent audit evidence |
| MSA | Master service agreement — umbrella contract for a vendor relationship |
| SOW | Statement of work — specific tasks, deliverables, timelines, and fees under an MSA |
| SLA | Service-level agreement — measurable performance commitments and penalties |
| MOU | Memorandum of understanding — non-binding statement of intent to cooperate |
| NDA | Non-disclosure agreement — binding promise to keep shared information confidential |
| BPA | Business partners agreement — terms governing an ongoing partnership's roles and responsibilities |
| Data controller | Organization deciding why and how personal data is processed; carries primary legal duty |
| Data processor | Organization processing personal data on a controller's behalf, following its instructions |
| Attestation | An independent auditor's formal statement that controls or conditions meet a standard |
| Patch latency | Elapsed time between a patch's release and its deployment across the environment |
Exercises
Exercise 1: Run the ALE math and judge a control
A small accounting firm stores client tax records on a file server environment valued at $90,000 (hardware, rebuild time, and the operational value of the data). Ransomware is the scenario.
- From incident data for similar firms, an event would render 40% of that value lost or unusable, and is expected once every five years. Compute EF, SLE, ARO, and ALE. (Check: SLE $36,000; ALE $7,200.)
- A proposed control — offline immutable backups plus EDR — costs $6,500 per year and would cut the exposure factor to 5%. Compute the new ALE and the annual risk reduction.
- Compare the risk reduction with the control's cost. Is the control financially justified on ALE alone? Write two sentences of justification you could give the firm's partners.
- Name one benefit of the control that ALE does not capture (hint: think about clients, regulators, and reputation).
Exercise 2: Build a risk register
A 40-person dental clinic is formalizing security. Using a 1–5 likelihood and 1–5 impact scale, create a risk register for the five risks below. Your register must have columns: Risk, Owner, Likelihood, Impact, Score, Response, and one control or next step.
- Ransomware encrypts the practice-management system containing patient records.
- A staff member emails a patient list to the wrong recipient.
- The imaging (X-ray) PC runs an unsupported operating system that cannot be replaced this year.
- The clinic's IT support vendor has a shared, always-on remote access account.
- A burst pipe floods the server closet.
Then: sort the register by score, mark each risk's heat-map zone (score 15–25 red, 8–14 amber, 1–7 green), and write one sentence explaining your highest-priority risk to the clinic's owner.
Exercise 3: Sort the documents and assign the roles
Part A. Classify each item as a policy, standard, procedure, or guideline:
- "Patient data must be protected in accordance with its classification." (approved by the board)
- "Disk encryption must use AES-256."
- "Suggested: keep a printed copy of the on-call rota in the server room."
- "To reset a password: verify the caller's ID, generate a temporary password, force a change at next login, log the ticket."
Part B. Assign each duty to data owner, data custodian, CISO, or DPO:
- Configure and test the nightly backups of the finance database.
- Decide that only the payroll team may access salary records, and approve exceptions.
- Present the annual security risk report to the board and request the security budget.
- Advise whether a proposed marketing use of customer data complies with privacy law, and act as contact for the regulator.
(Answer guide: Part A — 1 policy, 2 standard, 3 guideline, 4 procedure. Part B — 1 custodian, 2 owner, 3 CISO, 4 DPO.)
Exercise 4: Assess two vendors
Your company is choosing vendors in two categories. Apply the third-party lifecycle.
Vendor A — cloud payroll platform. Will store names, salaries, bank details, and tax IDs for all 600 employees. Provides a current SOC 2 Type II report, offers an SLA of 99.9% uptime, encrypts data in transit and at rest, and will sign a right-to-audit clause. Uses two sub-processors for hosting and support.
Vendor B — office snack delivery. No system access; staff pay by card at a self-serve kiosk the vendor maintains on your premises. No audit reports available; a one-page contract.
- Assign each vendor a risk tier and justify it in one sentence.
- Write five questionnaire questions appropriate for Vendor A that would not be proportionate for Vendor B.
- List the agreements you would put in place with Vendor A, and state the purpose of each in a few words.
- Identify two ongoing monitoring activities for Vendor A and one offboarding step for when the contract ends.
- Explain why Vendor B's kiosk still deserves one security question, and write it.
PBQ practice
Scenario — Meridian Legal LLP. You are the security analyst for a 120-person law firm. The risk committee has given you this register excerpt and asked you to prioritize treatment before the budget meeting.
| ID | Risk | Likelihood (1–5) | Impact (1–5) |
|---|---|---|---|
| --- | --- | --- | --- |
| R1 | Ransomware encrypts the document management system (all client files) | 4 | 5 |
| R2 | Phishing email leads to a compromised staff mailbox | 5 | 3 |
| R3 | The firm's IT support vendor's shared remote account is abused | 3 | 4 |
| R4 | An unencrypted laptop containing client documents is stolen | 2 | 4 |
| R5 | DDoS attack takes the client portal offline | 4 | 2 |
Additional data for R1: the document management environment is valued at $500,000. A ransomware event would destroy or lock up an estimated 30% of that value. Insurers and incident data suggest such an event roughly once every 2.5 years (ARO 0.4). A proposed program of network segmentation, immutable backups, and EDR would cost $35,000 per year and is expected to reduce the exposure factor to 10% and the ARO to 0.1.
Your tasks (write your answers as you would on paper):
- Calculate the risk score (likelihood × impact) for each risk and rank all five from highest to lowest. Note any tie and how you would break it.
- For each of the top three risks, choose a treatment (accept, mitigate, transfer, avoid) and justify it in 1–2 sentences, naming a specific control where you mitigate.
- For R1, compute the current SLE and ALE. Then compute the ALE with the proposed program in place, and state — with the numbers — whether the program is financially justified.
- Identify one risk (or part of one) you would transfer, name the mechanism, and state what responsibility the firm keeps even after transferring.
Model answer
- Scores and ranking: R1 = 4 × 5 = 20; R2 = 5 × 3 = 15; R3 = 3 × 4 = 12; R4 = 2 × 4 = 8; R5 = 4 × 2 = 8. Ranking: R1 (20) > R2 (15) > R3 (12) > R4 = R5 (8). R4 and R5 tie at 8; the tie is broken in favor of R4 first because its impact (4 — client confidentiality breach, legal privilege at risk) outweighs R5's impact (2 — inconvenience/outage of a portal with workarounds). Impact-first tie-breaking is standard because impact is harder to reduce after the fact.
- Treatments for the top three:
- R1 — Mitigate. It is the highest risk and squarely within the firm's power to reduce: segmentation, immutable backups, and EDR cut both likelihood of spread and blast radius. (Part of the residual financial risk is also transferred — see task 4.)
- R2 — Mitigate. Phishing is near-certain to keep arriving (likelihood 5), so reduce success and impact: MFA on all mailboxes, phishing simulations with coaching, and a one-click report button so real phishes are surfaced in minutes.
- R3 — Mitigate. Replace the shared vendor account with named individual accounts, MFA, just-in-time access that is disabled when no ticket is open, and session logging — backed by a right-to-audit clause in the vendor contract.
- R1 math: SLE = AV × EF = $500,000 × 0.30 = $150,000. Current ALE = SLE × ARO = $150,000 × 0.4 = $60,000/year. With the program: new SLE = $500,000 × 0.10 = $50,000; new ALE = $50,000 × 0.1 = $5,000/year. Annual risk reduction = $60,000 − $5,000 = $55,000, against a cost of $35,000/year — the program saves an expected $20,000/year in losses beyond its cost, so it is financially justified (before counting reputational and regulatory benefits).
- Transfer: Transfer part of R1's financial impact by purchasing cyber insurance sized to the residual exposure. The firm keeps full accountability to its clients and regulators — insurance pays bills; it does not restore client trust, meet notification duties, or answer to the bar association. (Acceptable alternative: transfer R5's availability risk to a DDoS-scrubbing/CDN provider under an SLA.)
End-of-chapter test
1. A company keeps suffering outages because engineers make undocumented configuration changes directly in production. Which governance control best addresses the root cause?
A. A formal change management process with approvals and backout plans
B. More frequent vulnerability scanning
C. A stricter password standard
D. Annual penetration testing
2. A server environment is valued at $80,000. An incident would cause a 25% loss, and it is expected once every 2.5 years (ARO 0.4). What is the ALE?
A. $50,000
B. $20,000
C. $8,000
D. $2,000
3. A clinic decides it can tolerate losing no more than one hour of patient data in a disaster. Which metric has it just defined?
A. MTTR
B. RPO
C. MTBF
D. ARO
4. A manufacturer buys cyber insurance to cover the financial cost of a potential plant-stopping ransomware event. Which risk response is this?
A. Avoid
B. Accept
C. Mitigate
D. Transfer
5. Which agreement specifies measurable uptime commitments and the penalties or credits owed when they are missed?
A. MOU
B. SLA
C. NDA
D. BPA
6. The head of HR decides which employees may view salary data and approves all access exceptions. The IT team then configures the permissions. What is the head of HR's role for this data?
A. Data custodian
B. Data processor
C. Data owner
D. DPO
7. A company discovers a breach exposing personal data of EU customers on Monday at 09:00. Under GDPR, by when must it notify the supervisory authority (assuming the breach is not unlikely to pose a risk)?
A. Within 24 hours
B. Within 72 hours
C. Within 30 days
D. At the next quarterly board meeting
8. A customer asks your company for independent proof that your security controls operated effectively throughout the year. Which artifact best answers this request?
A. Your internal self-assessment checklist
B. An external auditor's attestation report, such as a SOC 2 Type II
C. A screenshot of your firewall policy
D. A signed copy of your information security policy
9. The board asks whether the vulnerability management program is improving. Which metric best answers the question?
A. The number of scanners the company owns
B. The trend in mean time to remediate critical vulnerabilities over the last four quarters
C. The total number of vulnerabilities detected this month
D. The number of staff who attended security training
10. A business unit wants to keep using an unsupported legacy system for one more year. Security documents the decision, names an executive who approves it, and sets an expiry date for the decision. What is this?
A. Risk avoidance
B. A risk exception (documented acceptance above normal thresholds)
C. A penetration test finding
D. Risk transference
Answer key
- A — Undocumented, unreviewed changes are exactly what change management controls: requests, impact assessment, approval, testing, and a backout plan prevent surprise outages.
- C — SLE = $80,000 × 0.25 = $20,000; ALE = $20,000 × 0.4 = $8,000. (B is the SLE alone; the question asked for the annualized figure.)
- B — RPO (recovery point objective) is the maximum acceptable data loss expressed as time — here, one hour — and it drives backup/replication frequency.
- D — Insurance transfers the financial impact of the risk to a third party. The manufacturer still owns the operational and reputational consequences.
- B — An SLA (service-level agreement) contains measurable performance commitments such as uptime percentages, plus the remedies or credits owed when they are missed.
- C — The data owner is the business leader accountable for a data set who decides classification and approves access; the IT team implementing those decisions acts as custodian.
- B — GDPR requires notification of the supervisory authority within 72 hours of becoming aware of a qualifying personal-data breach.
- B — Attestation is an independent auditor's formal statement that controls met criteria over a period — unlike a self-assessment, it carries third-party credibility.
- B — Improvement is a trend in an outcome measure: falling remediation times for critical vulnerabilities show the program itself is getting faster, regardless of how many vulnerabilities scanners happen to find.
- B — Accepting a risk beyond normal approval levels is documented as a risk exception, with a named approver and an expiry date, so the acceptance is deliberate, owned, and revisited.
Want the full CompTIA Security+ (SY0-701) package?
This guide is free to read. Get the full SY0-701 practice exam — 865 questions plus 10 PBQs — with the complete PDF and 3 months of online access.
Get SY0-701 Full Access — $10