CompTIA SY0-701: Governance, Risk Management & Compliance — Study Guide

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.

Governance, Risk Management, and Compliance — collectively abbreviated GRC — is the connective tissue that binds technical security controls to organizational strategy, legal obligation, and financial reality. Where firewalls and endpoint agents defend systems, GRC defines why they exist, who owns them, and how their effectiveness is measured and reported. A mature GRC program transforms security from an ad hoc technical discipline into an auditable, repeatable business function.

Security Governance and Its Foundations

Security governance is the framework of authority, accountability, and decision-making that directs an organization’s security posture. Its most critical element is executive sponsorship, because without leadership commitment, policies become shelf-ware and budgets evaporate. Governance produces three tiers of documentation: policies (high-level, mandatory statements of intent approved by leadership), standards (specific, measurable requirements — for example, “TLS 1.3 minimum for all external endpoints”), procedures or SOPs (step-by-step operational instructions), and guidelines (recommended but non-mandatory practices). Confusing these tiers is a common pitfall; a policy states what and why, while a procedure states how.

Common organizational policies include the Acceptable Use Policy (AUP) governing employee use of corporate systems, password and access policies, data classification policies, incident response policies, and change management policies. Each is enforced through technical controls and disciplinary processes.

Risk Assessment and Quantitative Analysis

Risk management follows a lifecycle: identify assets and threats, assess likelihood and impact, treat the risk, and continuously monitor. Establishing scope is the first and often underappreciated step — it defines the boundaries of the assessment, including which systems, business units, data types, and threat scenarios are in play. Without a defined scope, assessments become unbounded and produce unreliable results.

Quantitative risk analysis uses monetary values to compare risks objectively. The foundational formulas are:

SLE (Single Loss Expectancy) = Asset Value × Exposure Factor
ARO (Annualized Rate of Occurrence) = Expected incidents per year
ALE (Annualized Loss Expectancy) = SLE × ARO

For example, if a ransomware event would cost $15,000 per occurrence and is expected to happen twice in three years, ARO equals 2 ÷ 3 ≈ 0.667, making ALE = $15,000 × 0.667 = $10,000 per year. A frequent error is neglecting to normalize ARO to an annual basis — if the frequency is given over multiple years, it must be divided accordingly. Another trap is using SLE alone to justify a control; a $500,000 SLE with an ARO of 0.01 (ALE = $5,000) rarely warrants a $50,000 annual control.

Qualitative analysis, by contrast, uses ordinal scales (Low/Medium/High or 1–5) and heat maps. It is faster and useful when hard financial data is unavailable, but it lacks precision for cost-benefit decisions.

Risk appetite and risk tolerance define how much risk leadership is willing to accept — appetite is the strategic level of acceptable risk, while tolerance describes acceptable deviation from that level. These must be defined before treatment decisions, since they set the threshold above which action is required.

Risk Treatment Strategies

Once assessed, each risk is treated using one of four strategies. Mitigation reduces likelihood or impact through controls — patching, segmentation, MFA. Transfer shifts financial consequences to a third party, most commonly through cyber insurance or contractual indemnification. Avoidance eliminates the risk by discontinuing the activity — for example, refusing to store certain data types. Acceptance is a formal, documented decision to take no action, typically when the cost of treatment exceeds the ALE.

A dangerous misconception is treating insurance as a substitute for mitigation. Insurance transfers financial impact but does nothing to prevent breaches, reputational damage, or regulatory penalties, many of which are explicitly excluded from cyber policies. Similarly, deploying a compensating control — an alternative safeguard when the primary control is infeasible — is a form of mitigation, not acceptance. If a legacy system cannot support MFA and is instead isolated on a segmented VLAN with enhanced logging, that segmentation is a compensating control, not accepted risk.

The Risk Register

The risk register is the central artifact of risk management. It documents each identified risk along with the responsible owner, likelihood and impact ratings, current controls, treatment strategy, residual risk, thresholds, and review dates. A well-maintained register enables leadership to prioritize spending and satisfies auditors that risk decisions are traceable. A typical register entry might read:

Risk ID: R-2024-017
Description: Unpatched Apache Struts on public web tier
Owner: Director of Infrastructure
Likelihood: High | Impact: High | Inherent Risk: Critical
Treatment: Mitigate — WAF virtual patch + emergency change window
Residual Risk: Medium | Threshold: Any exploit PoC published
Review Cadence: Weekly until closed

Risk assessments must be recurring, not point-in-time. Threat landscapes, business processes, and third-party relationships change continuously; an annual assessment supplemented by triggered reassessments (major acquisitions, new regulations, incidents) is the accepted standard.

Contracts and Service Agreements

Contractual instruments codify obligations between parties. The Master Service Agreement (MSA) establishes overarching legal terms governing the entire relationship. The Statement of Work (SOW) operates under an MSA and defines specific deliverables, timelines, and acceptance criteria for a particular engagement. The Service Level Agreement (SLA) specifies measurable performance commitments — uptime percentages, response times, penalties for missed metrics. A common error is conflating SOW and SLA: an SOW says “deliver a customer portal by Q3,” while an SLA says “the portal will maintain 99.9% availability with a four-hour incident response time.”

The Non-Disclosure Agreement (NDA) protects confidential information exchanged between parties. The Memorandum of Understanding (MOU) expresses intent to cooperate, typically non-binding. Business Partnership Agreements (BPA) govern joint ventures, and Interconnection Security Agreements (ISA) define technical and security requirements when two organizations connect systems directly.

Third-Party Risk and Supply Chain

Third-party risk management addresses the reality that an organization’s security posture extends to every vendor with access to its data or systems. Due diligence begins before contract signing — reviewing financial stability, security certifications, and incident history — and continues through the relationship via periodic reassessment, right-to-audit clauses, and continuous monitoring services.

Supply chain risk extends this to hardware, software, and firmware provenance. Software Bills of Materials (SBOMs), code signing verification, and vendor security questionnaires are increasingly mandatory. The SolarWinds compromise of 2020 demonstrated precisely how a trusted software update channel can itself become an attack vector: attackers inserted a backdoor (SUNBURST) into the Orion build pipeline, which was then cryptographically signed and distributed to approximately 18,000 customers as a legitimate update. No perimeter control stopped it because the malicious code arrived as a trusted, signed package from a known vendor. The lesson is that supply chain trust must be verified continuously, not assumed.

Attestations, Audits, and Regulatory Compliance

Independent assurance takes several forms. SOC 2 Type II reports, produced by licensed CPA firms under AICPA standards, evaluate a service organization’s controls over a period (typically 6–12 months) against the Trust Services Criteria. SOC 2 Type I covers a single point in time and is considerably weaker evidence. SOC 1 addresses financial reporting controls; SOC 3 is a public-facing summary. ISO/IEC 27001 certification demonstrates an operational Information Security Management System.

A critical distinction: an attestation is a formal declaration — sometimes made by the vendor itself (a self-attestation) and sometimes by an independent auditor. A vendor’s self-attestation carries far less evidentiary weight than an independent third-party audit report. Requesting “your SOC 2” and accepting a marketing PDF in return is a frequent procurement failure; the actual signed report from the auditing firm, with its opinion letter, is the required artifact.

Regulatory regimes impose specific obligations. PCI DSS governs cardholder data with prescriptive technical requirements — network segmentation, quarterly ASV scans, annual penetration tests. GDPR establishes rights for EU data subjects, mandates 72-hour breach notification, and authorizes fines up to 4% of global annual revenue. HIPAA protects U.S. health information, SOX governs financial reporting integrity, and GLBA applies to financial institutions. Compliance is a floor, not a ceiling — being PCI-compliant does not mean being secure, only that a defined baseline has been met at the time of assessment.

Practical Scenario: GRC Failure Leading to Regulatory Penalty

A regional healthcare network outsourced its billing platform to a third-party vendor without conducting security due diligence or including right-to-audit clauses in the contract. The vendor suffered a ransomware incident that exposed 340,000 patient records. Because the healthcare network had not performed a Business Associate Agreement (BAA) review, had no evidence of the vendor’s security controls, and had not conducted a risk assessment of the relationship, HHS OCR found the network in violation of HIPAA’s Security Rule. The resulting settlement included a $1.2 million fine and a two-year corrective action plan. The technical controls at the healthcare network itself were adequate; the failure was entirely in governance — no vendor risk program, no contractual security obligations, no periodic reassessment. This scenario illustrates that GRC failures are not abstract compliance deficiencies; they produce concrete, quantifiable financial and reputational harm.

All domains · Identity →

Practice these questions → · Timed practice on ExamRoll.io →