Governance,
Risk & Compliance

Governance, Risk, and Compliance is the organisational scaffolding through which a security programme is directed, measured, and held accountable. It is the discipline that answers the questions technical security cannot: Who is responsible for security? What level of risk is the organisation willing to accept? How does the organisation demonstrate to regulators, customers, and partners that its security controls are real and effective? These questions matter as much as any technical control — and they are answered through GRC.

Why GRC Cannot Be Siloed

Organisations that treat governance, risk, and compliance as separate programmes create predictable dysfunction. A compliance team that builds controls to satisfy an audit checklist without reference to the organisation's actual risk profile produces compliance theatre — documentation that satisfies auditors while leaving real threats unaddressed. A risk team that identifies and quantifies risk without governance authority to mandate remediation produces reports that gather dust. A governance function that sets policy without compliance mechanisms to verify adherence produces aspirational policy rather than operational reality.

Integrated GRC means: risk assessments inform which controls are required; governance establishes who is accountable for maintaining those controls; compliance verifies the controls are operating as designed. The cycle is continuous — compliance findings feed back into risk assessments, which drive governance decisions about remediation priority and resource allocation.

GRC and Technical Security — The Connection

A persistent tension in security organisations is the perceived divide between GRC practitioners ("the compliance people") and technical security teams ("the engineers"). This divide is unproductive and usually based on a misunderstanding of what each discipline contributes.

• The Security Operations Centre generates operational risk data — incident frequency, detection gaps, mean time to contain — that GRC needs to populate accurate risk assessments. Without SOC data, risk assessments are based on assumptions.
• Incident Response activates the governance processes defined by GRC — the IR plan, the escalation matrix, the regulatory notification obligations. The quality of those processes directly determines IR effectiveness.
• Detection Engineering implements the technical controls that compliance frameworks mandate. The Sigma rules and SIEM detections are the operational expression of control requirements.
• GRC provides the authority, the budget justification, and the regulatory mandate that enables technical security teams to get resources and organisational support for their work.

Neither GRC nor technical security is sufficient alone. An organisation with excellent GRC and weak technical controls has beautiful documentation and real vulnerabilities. An organisation with excellent technical controls and weak GRC has capable engineers operating without direction, accountability, or regulatory cover.

The Business Case for GRC

Security investment requires organisational justification, and GRC is the function that makes that justification. The business case rests on four pillars:

1. Regulatory avoidance — GDPR fines up to €20M or 4% of global turnover, HIPAA penalties reaching $1.9M per violation category per year, PCI-DSS fines from card brands for non-compliant breaches. These are quantifiable costs avoided by maintaining compliance.
2. Customer requirement — enterprise customers increasingly require SOC 2 Type II reports, ISO 27001 certification, or completed security questionnaires as a condition of doing business. GRC enables these commercial relationships.
3. Breach cost reduction — IBM's 2023 Cost of a Data Breach report found organisations with mature security programmes (strong governance, tested IR plans, deployed automation) reduced breach costs by an average of $1.8M compared to those without.
4. Insurance and financing — cyber insurers require evidence of security programme maturity. Organisations with immature GRC face higher premiums, lower coverage limits, or coverage denial. Some financing arrangements now include security programme requirements in covenant terms.

The GRC Career Landscape

GRC roles span a wide range of specialisations. Common titles include: GRC Analyst, Risk Analyst, Compliance Manager, Privacy Officer / DPO, Information Security Manager, CISO, Internal Auditor, Security Architect (governance-oriented), and GRC Consultant. The discipline rewards practitioners who can operate at both strategic and operational levels — who can brief a board on risk posture in the morning and review a vendor security questionnaire in the afternoon.

Security governance is the mechanism by which an organisation's leadership exercises oversight and control over its security programme. Without governance, security is whatever the most senior engineer on the team decides is important this quarter. With governance, security is a defined organisational priority with clear accountabilities, measured outcomes, and a direct line to executive decision-making.

The Board's Security Responsibilities

Boards of directors have fiduciary duties that extend to cybersecurity — a position reinforced by regulatory developments in recent years. The US Securities and Exchange Commission's 2023 cybersecurity disclosure rules require public companies to disclose material cybersecurity incidents within four business days and to describe annually their cybersecurity risk management, strategy, and governance processes. Many boards have responded by establishing dedicated security sub-committees or assigning security oversight to the audit committee.

What the board is responsible for: setting the risk appetite (the level of cyber risk the organisation is willing to accept), ensuring management has the resources to implement the security programme the risk appetite requires, receiving regular security briefings from the CISO, overseeing material incident response, and ensuring the organisation meets its regulatory obligations. What the board is not responsible for: the technical implementation of controls, specific tool selection, or operational security decisions.

The CISO Role

The Chief Information Security Officer is the executive accountable for the security programme. The role's effectiveness depends critically on: reporting line, authority, and the organisation's genuine commitment to security outcomes.

• Reporting line — a CISO who reports to the CIO has a structural conflict of interest: the CIO's performance metrics (uptime, feature delivery speed, cost) often compete with security requirements. Best practice is for the CISO to report to the CEO, COO, or directly to the board's audit/risk committee. This provides independence and direct access to business decision-makers.
• Authority — a CISO who can recommend security controls but cannot enforce them is an advisor, not an executive. Effective CISOs have the authority to set security standards, mandate compliance with those standards, and escalate non-compliance to leadership with consequences.
• Accountability without authority — a damaging pattern in which the CISO is held responsible for security outcomes but does not control the resources, decisions, or organisational behaviour that determine those outcomes. When this occurs, CISO tenure shortens and programme continuity suffers.

Security Policy Architecture

The four-level policy hierarchy is one of the most practically important concepts in governance — and one of the most consistently confused. Understanding the distinctions prevents the common failure mode of writing a 200-page "policy" that attempts to be all four levels simultaneously and ends up being none of them effectively.

A real-world example: the Password Policy states that accounts must use strong authentication. The Password Standard specifies minimum length (14 characters), complexity requirements, maximum age (90 days for non-MFA accounts), and prohibited reuse (last 24 passwords). The Password Reset Procedure documents step-by-step how a helpdesk analyst resets a locked account. The Password Guideline recommends password managers and explains how to construct memorable strong passphrases.

Writing Effective Policies

Security policies fail in predictable ways: they are too long to read, too vague to audit, too technical for their audience, or never updated after initial approval. Effective policy writing principles:

• State the requirement positively and specifically — "All endpoints must have approved endpoint protection software installed and active" rather than "Endpoint security should be considered"
• Define scope explicitly — who does this policy apply to? Employees? Contractors? Vendors? All systems? Only those handling regulated data?
• Include an exception process — every policy must have a documented, approved way to request an exception. Policies without exception processes produce undocumented workarounds.
• State consequences of non-compliance — "Violations may result in disciplinary action up to and including termination" provides the governance teeth the policy needs
• Set a review date — a policy that has not been reviewed in three years may be dangerously out of date

The Three Lines of Defence Model

The Three Lines model (updated by the IIA in 2020) provides a framework for understanding how governance, risk, and assurance responsibilities are distributed across the organisation:

• First line — Operational Management: the business units and IT operations teams that own and operate controls day-to-day. They implement security controls, manage risk within their domains, and are the primary defence against threats.
• Second line — Risk and Compliance Functions: the GRC team, legal, and compliance functions that provide oversight of the first line, maintain the risk framework, set policy standards, and provide independent challenge to first-line risk management. They do not own the risks — the first line does.
• Third line — Internal Audit: provides independent assurance to the board and senior management that the first and second lines are operating effectively. Internal audit has no ownership of controls or risk — only assurance responsibilities.

Security Culture as a Governance Outcome

Security culture — the degree to which security is genuinely valued and practised across the organisation, not just in the security team — is the highest-leverage governance outcome and the hardest to achieve. It cannot be mandated by policy or measured by a single metric. It develops through: visible leadership commitment (executives who discuss security seriously and hold themselves to the same standards they require of staff), meaningful consequences for security failures and recognition for security-positive behaviour, and a security function that is helpful rather than obstructive — that says "here is how to do this securely" rather than simply "no".

Risk management is the analytical core of GRC. Without it, governance is opinion and compliance is checkbox-ticking. With rigorous risk management, the organisation can make rational, evidence-based decisions about where to invest security resources, what level of residual risk to accept, and how to communicate security priorities to business leadership in language they understand and can act on.

Risk Management Frameworks

• NIST Risk Management Framework (RMF — SP 800-37) — a six-step process (Prepare, Categorise, Select, Implement, Assess, Authorise, Monitor) designed for US federal agencies and their contractors. Highly structured, documentation-intensive, and authoritative for FedRAMP and FISMA compliance.
• ISO 31000 — a high-level, principle-based international standard for risk management applicable across all industries. Describes principles and a generic framework; does not prescribe specific methods. Used as the governance backdrop for many organisation-specific risk frameworks.
• FAIR (Factor Analysis of Information Risk) — a quantitative risk analysis framework that produces monetary loss estimates from structured analysis of threat and vulnerability factors. The only framework designed to answer "how much does this risk cost us?" in financial terms.

Qualitative vs Quantitative Risk Assessment

FAIR — Factor Analysis of Information Risk

FAIR is the most rigorous and widely adopted quantitative risk framework for information security. It decomposes risk into a hierarchy of factors that can be estimated independently and combined to produce a probability-weighted range of monetary loss. Understanding FAIR's structure is essential for practitioners who need to communicate risk in financial terms to business leaders.

Risk Appetite, Tolerance, and Threshold

These three terms are among the most consistently conflated in risk management:

• Risk appetite — the amount and type of risk the organisation is willing to pursue or accept in order to achieve its objectives. A strategic statement: "We accept moderate cyber risk in pursuit of aggressive cloud adoption." Set by the Board.
• Risk tolerance — the acceptable variation around the risk appetite. The operational boundaries within which management operates: "We will maintain no more than $5M in unmitigated cyber risk exposure at any time."
• Risk threshold — the level at which risk exposure triggers escalation to a higher governance level. "Any single risk exceeding $2M in ALE must be escalated to the Risk Committee for explicit acceptance or treatment direction."

Risk Treatment Options

• Mitigate — implement controls that reduce the likelihood or impact of the risk. The most common treatment; includes technical controls (MFA, EDR, patching), process controls (IR plan, access reviews), and people controls (training).
• Transfer — shift the financial consequences of the risk to a third party. Cyber insurance is the primary transfer mechanism. Note: insurance transfers the financial loss but not the operational impact or reputational damage.
• Avoid — cease the activity that creates the risk. Shutting down a vulnerable legacy system, exiting a high-risk market, or declining to store a category of sensitive data to avoid the associated regulatory risk.
• Accept — acknowledge the risk and choose to operate without additional controls, because the cost of treatment exceeds the expected loss or the risk is within appetite. Acceptance must be explicit and documented — implicit acceptance (not noticing a risk or deferring a decision indefinitely) is not a risk treatment.

The Risk Register

The risk register is the organisation's living inventory of identified risks, their assessments, owners, treatments, and residual risk status. A well-maintained risk register is the operational artefact that makes risk management real rather than theoretical. It should contain:

• Risk ID, name, and description
• Risk category (strategic, operational, compliance, financial, reputational)
• Inherent risk rating (before controls)
• Current controls in place
• Residual risk rating (after controls)
• Risk owner (accountable individual, not a team)
• Treatment plan with actions, owners, and due dates
• Risk acceptance record (if accepted) with authorising executive signature
• Last review date and next scheduled review

Threat modelling is the structured process of identifying, communicating, and addressing security threats and mitigations within the context of protecting a specific system or application. It belongs in both engineering (where it informs secure design decisions) and GRC (where it provides the threat analysis that populates risk registers and drives control selection). This chapter covers the practitioner's toolkit: the methodologies, the artefacts, and the process for running effective threat modelling sessions.

STRIDE

STRIDE is a threat categorisation mnemonic developed at Microsoft that organises threats by the type of violation they represent. It is most effective as a prompting tool during threat identification — systematically asking "could an attacker do X to this component?" for each category:

STRIDE is applied per-component in a Data Flow Diagram (DFD). For each process, data store, data flow, and external entity, the analyst systematically considers whether each STRIDE threat is applicable. This systematic approach ensures coverage — it is harder to miss a threat category when you are explicitly checking for each one.

PASTA — Process for Attack Simulation and Threat Analysis

PASTA is a seven-stage risk-centric threat modelling methodology that aligns threat analysis with business objectives and produces output suitable for risk registers and security investment decisions. Unlike STRIDE (which is threat-centric), PASTA is attacker-centric — it models from the attacker's perspective to identify what they would actually try to do.

1. Define business objectives — what does this system need to do? What business processes depend on it? What regulatory obligations does it carry?
2. Define technical scope — the system components, infrastructure, and interfaces in scope for the model
3. Application decomposition — Data Flow Diagrams, trust boundaries, asset identification, privilege levels
4. Threat analysis — identify applicable threats using threat intelligence relevant to this application type and sector
5. Vulnerability and weakness analysis — identify existing vulnerabilities in the system components
6. Attack modelling — construct attack trees showing how identified threats would exploit identified vulnerabilities
7. Risk and impact analysis — score attack scenarios by likelihood and business impact; prioritise mitigations

Data Flow Diagrams and Trust Boundaries

A Data Flow Diagram is the foundational artefact for most threat modelling methodologies. It maps: processes (circles — the software components that transform data), data stores (parallel lines — where data persists), data flows (arrows — data moving between components), and external entities (rectangles — actors outside the system boundary).

Trust boundaries are lines on the DFD that separate areas with different trust levels. Data crossing a trust boundary is a threat modelling hot spot — every crossing should be examined for: authentication (does the receiving side verify who is sending?), authorisation (is the sender permitted to send this data?), integrity (could the data have been tampered with in transit?), and confidentiality (could an adversary observe the data?).

Common trust boundaries: Internet to DMZ, DMZ to internal network, user process to privileged process, client to server, microservice to microservice, human user to application.

Attack Trees

Attack trees decompose an attacker's objective into sub-goals and the methods to achieve each. The root node is the attacker's ultimate goal (e.g., "Exfiltrate customer PII"). Child nodes represent sub-objectives (e.g., "Gain access to the customer database"). Leaf nodes represent specific attack methods (e.g., "SQL injection via the search endpoint", "Steal DBA credentials via phishing").

Attack trees serve two purposes: they ensure comprehensive coverage of attack paths (a threat model that only considers the obvious attack misses the effective one) and they enable prioritisation by probability — the most likely paths through the tree reveal where controls will have the most impact.

Mapping to MITRE ATT&CK

Threat model findings should be mapped to MITRE ATT&CK techniques to connect the threat modelling output to detection engineering priorities. If the threat model for a web application identifies "SQL injection to extract credentials from the database backend" as a high-probability attack path, and this maps to T1190 (Exploit Public-Facing Application) and T1078.001 (Valid Accounts: Default Accounts), the detection engineer knows to look for existing detection coverage of these techniques and build it if absent.

This linkage — threat model → ATT&CK technique → detection coverage gap → detection engineering backlog item — is the mechanism by which GRC threat modelling drives operational SOC improvement.

Security control frameworks provide structured catalogues of security practices organised in ways that enable systematic programme building, gap analysis, and maturity assessment. The challenge for practitioners is the proliferation of frameworks — every regulator, standards body, and industry group has produced one — and the genuine business need to demonstrate compliance with multiple simultaneously. This chapter covers the major frameworks and the practical approach to using them together without duplicating effort.

CIS Controls v8

The Center for Internet Security Controls (now v8, released 2021) are 18 prioritised security controls representing the consensus of a global community of security practitioners. They are notable for two qualities: they are highly actionable (each control is broken down into specific Safeguards that can be implemented and measured) and they are prioritised by risk (Implementation Group 1 — IG1 — are the minimum controls every organisation should have regardless of size or sector).

NIST Cybersecurity Framework 2.0

The NIST CSF, updated to version 2.0 in February 2024, is the most widely referenced cybersecurity framework globally. CSF 2.0 adds a sixth function — Govern — to the original five, acknowledging that governance is the foundation for everything else.

• GOVERN (new in 2.0) — establishes organisational context, risk management strategy, supply chain risk management, roles and responsibilities, and programme oversight
• IDENTIFY — asset management, business environment, risk assessment, risk management strategy
• PROTECT — identity management, awareness training, data security, protective technology, maintenance
• DETECT — anomaly detection, continuous monitoring, detection processes
• RESPOND — response planning, communications, analysis, mitigation, improvements
• RECOVER — recovery planning, improvements, communications

The CSF is outcome-oriented — it describes what the security programme should achieve, not how to achieve it. This makes it powerful for programme assessment and board communication but requires other frameworks (CIS Controls, ISO 27002) to provide the implementation detail.

ISO 27001 and ISO 27002

ISO 27001 is the international standard for Information Security Management Systems (ISMS). It specifies requirements that an organisation must meet to achieve certification. ISO 27002 is the companion code of practice — it provides guidance on implementing the controls in Annex A of ISO 27001.

The 2022 revision restructured Annex A from 114 controls in 14 domains to 93 controls in 4 themes: Organisational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). Five new controls were added, including threat intelligence, information security for cloud services, and ICT readiness for business continuity.

ISO 27001 certification is increasingly a customer requirement, particularly in B2B technology, financial services, and healthcare sectors. Chapter 7 covers the certification process in depth.

SOC 2 Trust Services Criteria

SOC 2 is an assurance framework developed by the AICPA, assessed by a licensed CPA firm, and reported in a Type I (point-in-time) or Type II (over a 6–12 month period) audit report. It evaluates five Trust Services Criteria:

• Security (CC — Common Criteria) — mandatory for all SOC 2 examinations. Covers logical access, change management, risk assessment, monitoring, and incident response.
• Availability — system availability meets commitments to users
• Processing Integrity — system processing is complete, accurate, timely, and authorised
• Confidentiality — information designated confidential is protected as committed
• Privacy — personal information is collected, used, retained, disclosed, and disposed of in accordance with commitments

SOC 2 Type II reports are the standard trust mechanism in the US SaaS market — enterprise customers routinely request them as a condition of vendor evaluation. Chapter 7 compares ISO 27001 and SOC 2 for programme selection decisions.

Building a Unified Control Set

Most mature organisations must satisfy multiple frameworks simultaneously: ISO 27001 for international enterprise customers, SOC 2 for US customers, PCI-DSS for cardholder data environments, and GDPR for EU personal data. Implementing each framework independently duplicates enormous effort — the same access control requirements appear in all of them.

A unified control set maps a single catalogue of implemented controls against the requirements of all applicable frameworks. When an auditor asks for evidence of access management controls, the same evidence satisfies ISO 27001 Annex A control 8.2, SOC 2 CC6.1, PCI-DSS Requirement 7, and CIS Control 5 simultaneously. Tools like the Unified Compliance Framework (UCF) and GRC platforms provide pre-built mapping tables that dramatically reduce this effort.

The regulatory landscape for cybersecurity and privacy has expanded dramatically in the past decade — and the pace of new regulation is accelerating. Practitioners who understand only the regulations affecting their current role will find themselves behind when their organisation expands geographically, acquires a company in a new sector, or when a new regulation comes into force. This chapter provides the grounding across all major frameworks that every GRC professional needs.

GDPR — General Data Protection Regulation

GDPR's six lawful bases for processing personal data are central to any privacy programme: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Most B2B data processing relies on legitimate interests or contract; B2C marketing typically requires consent. The lawful basis determines the data subject's rights — consent-based processing must be as easy to withdraw as to give; legitimate interests processing can be objected to.

The accountability principle — Article 5(2) — requires organisations to not only comply with GDPR but to demonstrate compliance. This is where GRC documentation becomes legally significant: the Records of Processing Activities (RoPA), DPIAs, Data Transfer Impact Assessments, and privacy notices are the evidence of accountability that regulators require during investigations.

HIPAA — Health Insurance Portability and Accountability Act

The HIPAA Security Rule's distinction between Required and Addressable safeguards is frequently misunderstood. "Addressable" does not mean optional — it means the covered entity must implement the safeguard if reasonable and appropriate, or document why it is not reasonable and appropriate and implement an equivalent alternative. Treating addressable safeguards as optional is a common HIPAA compliance failure.

PCI-DSS v4.0

PCI-DSS v4.0's most significant change is the introduction of the Customised Approach — an alternative to the traditional "Defined Approach" that allows organisations to implement controls in ways that achieve the stated security objective through means other than those explicitly listed in the requirements. This provides flexibility for innovative security architectures but requires rigorous documentation and QSA validation. Most organisations will continue with the Defined Approach for the majority of requirements.

SOX — Sarbanes-Oxley Act (IT Controls)

SOX is a US corporate governance law (2002) that, through Section 404, requires management and external auditors to report on the adequacy of internal controls over financial reporting. IT General Controls (ITGCs) are the IT controls that underpin the reliability of financial systems and the data they produce.

The four ITGC domains most relevant to GRC practitioners:

• Change Management — controls over how changes to financial systems are approved, tested, and deployed. Segregation of duties between development, testing, and production.
• Access Management — controls over who can access financial systems and data. User access reviews, privileged access management, separation of duties.
• Computer Operations — controls over production environment stability: backup and recovery, job scheduling, incident management.
• Program Development — controls over the development and implementation of new financial applications.

DORA — Digital Operational Resilience Act

Building a Regulatory Inventory

Most organisations are subject to multiple overlapping regulations. The first step in any compliance programme is a comprehensive regulatory inventory — a documented mapping of which regulations apply, why, and what their key obligations are. Inputs to a regulatory inventory:

• Data types held — personal data of EU residents (GDPR), health information (HIPAA), payment card data (PCI-DSS), children's data (COPPA)
• Geographic footprint — countries of operation, where data is processed, where customers are located
• Industry sector — financial services (DORA, GLBA, SOX), healthcare (HIPAA), energy (NERC CIP), government contracting (CMMC, FedRAMP)
• Listed status — public companies (SEC disclosure rules, SOX)
• Customer contracts — contractual security requirements that create compliance obligations beyond statutory regulation

ISO 27001 is the world's most widely recognised information security management standard, with over 70,000 organisations certified globally. It is important to understand what ISO 27001 certifies: not a set of controls, but a management system — the documented, implemented, and continuously improved processes through which an organisation manages information security risk. An organisation can have excellent technical controls and fail ISO 27001 certification if it cannot demonstrate the management processes that govern those controls.

The ISMS Structure — Clauses 4 to 10

ISO 27001's mandatory requirements are in Clauses 4–10. Annex A contains the control objectives and controls (implemented based on the risk assessment, not mandatorily).

The Scope Decision

The ISMS scope defines what is covered by the certification — which parts of the organisation, which systems, which processes, and which locations. Scope is one of the most consequential decisions in an ISO 27001 programme because it determines the work required to achieve and maintain certification.

A narrow scope (e.g., "the cloud-hosted SaaS product and associated development and operations processes") achieves certification faster and with less ongoing effort. But narrow scoping carries a reputational risk: sophisticated customers and auditors will scrutinise whether the scope covers the parts of the business relevant to their security interests. A scope that excludes the corporate network, HR systems, and finance functions from a SaaS company's ISO 27001 certificate may satisfy the standard but will not satisfy a careful customer's due diligence.

Gap Analysis

The gap analysis compares the organisation's current state against ISO 27001's requirements and identifies what must be implemented, documented, or improved to achieve certification. A structured gap analysis assesses:

• Existence of required documented information (Clause 7.5 — which documents ISO 27001 mandates)
• Implementation of mandatory processes (risk assessment, internal audit, management review, nonconformity management)
• Selection and implementation of Annex A controls relevant to the risk assessment results
• Evidence that controls are operating effectively, not just documented

The gap analysis output is a remediation roadmap. Organisations typically need 6–18 months from gap analysis to Stage 2 certification audit, depending on current maturity and scope complexity.

The Statement of Applicability (SoA)

The Statement of Applicability is one of the most important documents in an ISO 27001 ISMS. It lists all 93 Annex A controls, states for each control whether it is applicable, the justification for inclusion or exclusion, and whether it has been implemented. The SoA is the bridge between the risk assessment (which identifies risks) and the control set (which addresses those risks). Auditors will scrutinise the SoA carefully — exclusions must be justified by the risk assessment results, and inclusions must be demonstrably implemented.

The Certification Audit Process

1. Certification body selection — select an accredited certification body (BSI, Bureau Veritas, Schellman, A-LIGN, etc.). Accreditation body (UKAS in the UK, DAkkS in Germany, ANAB in the US) ensures the CB is competent to audit against the standard.
2. Stage 1 Audit (Documentation Review) — the auditor reviews the ISMS documentation: scope, SoA, risk assessment methodology and results, risk treatment plan, key policies and procedures. Stage 1 is typically conducted remotely. Output: Stage 1 report identifying any "major non-conformities" (blocking issues) or "minor non-conformities" (issues to address before Stage 2).
3. Stage 2 Audit (Implementation Audit) — typically 1–5 days on-site (depending on scope size), the auditor tests whether controls are implemented and operating as described in the documentation. Interviews with staff, review of records and evidence, technical testing. Output: Stage 2 report; if no major non-conformities remain, certificate is issued.
4. Surveillance Audits — annual lightweight audits in years 1 and 2 of the 3-year certification cycle, verifying the ISMS is maintained and improved.
5. Recertification Audit — full audit at the end of the 3-year cycle to renew the certificate.

ISO 27001 vs SOC 2 — When to Pursue Which

For most B2B SaaS companies selling into the US market: pursue SOC 2 Type II first, as it is the most commonly required by US enterprise customers and achievable in a shorter timeframe. Add ISO 27001 when expanding internationally or when specific international customers require it. The controls required by both are substantially overlapping — a company pursuing both can share evidence across the two programmes with a unified control set.

Privacy is a governance domain that has achieved regulatory prominence to match (and in some jurisdictions exceed) cybersecurity in terms of enforcement activity and financial penalties. The privacy programme and the security programme are deeply intertwined — the same breach that triggers a GDPR Article 33 notification also requires a cybersecurity incident response. But privacy governance has distinct requirements, distinct artefacts, and distinct organisational roles that security practitioners must understand even if they are not primarily privacy specialists.

GDPR's Seven Principles

Article 5 of GDPR establishes seven principles that govern all processing of personal data. These principles are not aspirational — they are legally binding requirements, and every data processing activity must be able to demonstrate compliance with each:

1. Lawfulness, fairness, and transparency — processing must have a lawful basis; individuals must be informed of how their data is used
2. Purpose limitation — data collected for one purpose cannot be used for an incompatible purpose without new lawful basis or consent
3. Data minimisation — collect only what is necessary for the stated purpose
4. Accuracy — personal data must be kept accurate and up to date; inaccurate data must be corrected or deleted
5. Storage limitation — data should not be retained longer than necessary for its purpose
6. Integrity and confidentiality — processing must ensure appropriate security (the security principle — this is where cybersecurity meets privacy regulation)
7. Accountability — the controller is responsible for, and must be able to demonstrate, compliance with all other principles

Data Protection Impact Assessments (DPIAs)

A DPIA is a structured risk assessment of data processing activities that are "likely to result in a high risk" to individuals' rights and freedoms. GDPR Article 35 mandates DPIAs for specific processing types: large-scale processing of special category data, systematic monitoring of public areas, automated decision-making with significant effects.

A DPIA has four components:

1. Description — what data is processed, by whom, for what purpose, how long it is retained
2. Necessity and proportionality — is this processing necessary? Could the purpose be achieved with less data or lower risk?
3. Risk assessment — identify risks to individuals (not the organisation): identity theft, discrimination, financial loss, reputational damage, loss of control over personal data
4. Risk mitigation — controls that reduce identified risks; residual risk assessment; if residual risk remains high, consult the supervisory authority before proceeding

Privacy by Design

Privacy by Design (PbD) is the principle that privacy protections should be embedded into systems and processes from the outset — designed in, not bolted on. Ann Cavoukian's seven foundational principles:

• Proactive not reactive — prevent privacy risks rather than remediate them after they occur
• Privacy as the default — if a user takes no action, the most privacy-protective setting applies automatically
• Privacy embedded into design — privacy is a core feature, not an add-on
• Full functionality — positive sum — privacy and functionality are not zero-sum; both can be achieved simultaneously
• End-to-end security — data is protected throughout its lifecycle
• Visibility and transparency — individuals can verify that their data is handled as stated
• Respect for user privacy — keep it user-centric; data subjects' interests are the organising principle

GDPR's Article 25 gives Privacy by Design legal force — it requires controllers to implement "appropriate technical and organisational measures" to embed data protection principles and safeguards into processing activities.

Data Classification

A data classification scheme categorises data by its sensitivity and the handling requirements that apply to each level. Most organisations use 3–4 levels:

The most common data classification failure is producing a classification scheme that employees cannot apply in practice because the categories are too abstract. Practical schemes provide concrete examples of each level and simple decision criteria: "If this data were published in a newspaper, would it harm the company?" (Confidential or above). "Could this data identify an individual?" (personal data obligations apply).

Data Inventory and Flow Mapping

You cannot protect data you do not know you have. A data inventory identifies every category of personal and sensitive data held by the organisation, the systems it exists in, where it came from, who can access it, and where it flows. Data flow mapping extends the inventory to show how data moves between systems, teams, and third parties — often revealing sharing that was not intentional or approved.

Data flow mapping is required to populate the Record of Processing Activities (RoPA), to conduct meaningful DPIAs, and to determine the scope of a breach when one occurs. An organisation without a current data map cannot answer "what data was affected?" in the first 72 hours of a breach investigation — making accurate GDPR notification impossible.

Records of Processing Activities (RoPA)

GDPR Article 30 requires controllers and processors to maintain records of processing activities. The RoPA is the formal inventory of all personal data processing within the organisation. Each processing activity entry must include: the name and contact details of the controller, the purposes of the processing, the categories of data subjects and personal data, the categories of recipients, details of international transfers, retention periods, and a general description of technical and organisational security measures.

Cross-Border Data Transfers

Transferring personal data outside the European Economic Area requires a lawful transfer mechanism. The three primary mechanisms post-Schrems II:

• Adequacy decision — the European Commission has determined that the destination country provides adequate data protection. Current adequacy decisions: UK, Switzerland, Japan, South Korea, and the US (under the EU-US Data Privacy Framework, adopted 2023).
• Standard Contractual Clauses (SCCs) — pre-approved contractual terms that impose GDPR-equivalent obligations on the data importer. The 2021 SCCs are the current standard; they require a Transfer Impact Assessment (TIA) to assess whether the destination country's laws undermine the SCC protections.
• Binding Corporate Rules (BCRs) — intra-group transfer mechanisms for multinational companies. Require supervisory authority approval; significant investment but provide comprehensive intra-group transfer coverage.

The modern enterprise does not operate in isolation. The average large organisation has hundreds of vendors with some form of access to its data, systems, or networks — cloud providers, SaaS applications, managed service providers, professional services firms, and technology suppliers. Each of these relationships extends the organisation's attack surface beyond what it directly controls. Third-party risk management is the governance function that systematically addresses this extended exposure.

Third-Party Risk Lifecycle

1. Identification and scoping — maintain an inventory of all third parties. This alone is more difficult than it sounds — shadow procurement (business units engaging vendors without IT or security involvement) creates undiscovered suppliers constantly.
2. Initial due diligence — before engaging a new vendor, assess their security posture proportionate to the access and data they will have. Critical vendors get a full assessment; low-risk vendors may require only a brief questionnaire or review of a public SOC 2 report.
3. Contracting — security requirements embedded in the contract: the specific security standards the vendor must meet, right to audit, breach notification timeline (typically shorter than regulatory requirements to give the organisation time to comply), sub-processor approval, data handling requirements, and return/deletion of data on contract termination.
4. Onboarding — technical integration with appropriate access controls; minimum necessary access principle; documented access inventory.
5. Ongoing monitoring — periodic reassessment proportionate to risk tier; monitoring for security incidents affecting the vendor; reviewing new SOC 2 reports or certifications annually.
6. Offboarding — formal process to revoke access, confirm data deletion/return, and close the vendor relationship securely.

Vendor Tiering

Not all vendors require the same oversight. Vendor tiering allocates assessment effort proportionate to risk:

Beyond Questionnaires

Security questionnaires — whether proprietary, SIG (Standardised Information Gathering questionnaire), or CAIQ (Cloud Security Alliance Consensus Assessment Initiative Questionnaire) — have well-known limitations. They are self-reported, not independently verified, and can be completed inaccurately (deliberately or through misunderstanding). Better assurance mechanisms:

• SOC 2 Type II reports — independently audited over a 12-month period. Much stronger assurance than a self-attestation. Request the full report (under NDA), not just the executive summary.
• ISO 27001 certificate — verify certificate validity on the certification body's certificate register, not just from the vendor. Certificates can lapse.
• Penetration test results — request the executive summary and remediation status. The scope and recency of the test matter.
• Continuous monitoring tools — SecurityScorecard, BitSight, and similar platforms provide continuous outside-in assessment of vendors' publicly observable security posture (open ports, SSL certificate health, breach data exposure, DNS configuration).

Fourth-Party Risk

Fourth-party risk is the risk posed by your vendors' vendors — the sub-processors and subcontractors in your supply chain that you have no direct relationship with but whose failures can affect you. GDPR Article 28 requires data processors to obtain approval before engaging sub-processors and to flow down equivalent data protection obligations. But beyond GDPR, fourth-party risk is a genuine operational concern: a critical vendor's infrastructure provider suffering a breach can affect the critical vendor's services, which affects your organisation.

Supply Chain Attack Threat Model

The SolarWinds compromise (2020) demonstrated that a single supply chain attack could simultaneously compromise thousands of organisations with no direct vulnerability in their own systems. The attacker compromised SolarWinds' build infrastructure, inserting a backdoor into legitimate software updates that were then signed, distributed, and installed by SolarWinds' customers — including US government agencies and security companies.

The GRC response to supply chain risk:

• Software Bill of Materials (SBOM) requirements — requiring vendors to provide a complete inventory of software components in their products
• Build pipeline security assessments — evaluating whether vendor development and build processes have appropriate security controls
• Change notification requirements — contract provisions requiring vendors to notify you of significant changes to their infrastructure or software
• Monitoring for vendor-associated IOCs — ensuring the SOC is aware of incidents affecting critical vendors and has hunting capability to search for associated indicators

Assurance is the evidence-based confidence that security controls are working as designed. It is different from compliance (which verifies that controls exist) and different from security monitoring (which detects when controls fail). Assurance answers: are the controls we have documented actually operating effectively? Are they reducing the risks they were designed to address? This chapter covers the assurance mechanisms that answer these questions — and how to manage the relationships and processes that make assurance genuinely useful rather than a checkbox exercise.

Types of Security Audit and Assurance

Internal Audit's Role in Security

Internal audit (the third line) provides independent assurance to the board and senior management that governance, risk management, and internal controls are working effectively. In the security context, internal audit assesses whether: the ISMS (or equivalent) is operating as documented; security risks are being identified, assessed, and treated in accordance with policy; the security programme is achieving its stated objectives; and management's assertions about control effectiveness are accurate.

What internal audit is not: a management consulting function that designs controls (that would compromise independence), a substitute for external certification, or a function with authority to direct remediation. Internal audit reports findings; management owns remediation.

Evidence Collection and Audit Preparation

Preparing for an audit — whether internal or external — is significantly easier when evidence management is continuous rather than episodic. Organisations that scramble to gather evidence in the weeks before an audit are experiencing the cost of not having an always-ready evidence library. GRC platforms (Vanta, Drata, Tugboat Logic) automate evidence collection by continuously querying systems of record: pulling IAM access reviews from HR systems, configuration compliance from cloud posture tools, and patch status from vulnerability scanners.

Penetration Testing vs Vulnerability Scanning vs Red Team

Penetration tests and red team exercises are fundamentally different assurance activities. A penetration test assesses whether specific systems can be compromised. A red team exercise assesses whether the organisation's detection and response capability would catch a real attacker pursuing a realistic objective. Many organisations conduct annual penetration tests and believe they are conducting red team exercises — they are not. Red team requires prior investment in detection and response capability; testing an immature SOC with a red team exercise produces findings that are obvious and not actionable.

Findings Management

Audit findings are only valuable if they drive improvement. A common and dysfunctional pattern: findings are reported, management agrees to remediate, and the remediation never happens because there is no tracking mechanism and no accountability. Effective findings management:

• Assign an owner — every finding has a named individual (not a team) accountable for remediation
• Set a due date — based on severity: critical findings within 30 days; high within 90 days; medium within 180 days
• Track in the risk register — open audit findings are open risks; they belong in the same tracking system
• Exception process — if a finding cannot be remediated by the due date, a formal exception with documented residual risk acceptance is required — not a silent extension
• Report to leadership — the percentage of audit findings closed on time is a GRC metric that boards should see

Business continuity and disaster recovery planning is risk management applied to operational disruption. Where risk assessment identifies threats and evaluates their likelihood and impact, BC/DR planning addresses the "what do we do if it actually happens?" question — ensuring that when significant disruptions occur, the organisation can continue its most critical activities and recover its full operational capability within acceptable timeframes. Ransomware has made BC/DR planning more urgently relevant to security practitioners than at any previous point in the discipline's history.

Business Impact Analysis (BIA)

The BIA is the foundation of both the BCP and DRP. It identifies which business processes are critical, how long they can be disrupted before the disruption causes unacceptable business harm, and what minimum resources are required to sustain them during a disruption.

The BIA produces two critical parameters for every critical process:

• RTO (Recovery Time Objective) — the maximum acceptable time between disruption and restoration of the process to its minimum acceptable level. If an e-commerce platform's RTO is 4 hours, the DR plan must be capable of restoring basic transaction processing within 4 hours of a declared disaster.
• RPO (Recovery Point Objective) — the maximum acceptable data loss measured in time. An RPO of 1 hour means the organisation can tolerate losing at most 1 hour of transactions or data changes. This directly drives backup frequency requirements.

BCP vs DRP

The BCP and DRP are frequently conflated but serve different purposes:

• Business Continuity Plan (BCP) — addresses how the organisation maintains critical business functions during a disruption. It is people and process-oriented: who does what, using what manual workarounds, to maintain which minimum service levels. The BCP applies when the technology-dependent normal way of working is unavailable.
• Disaster Recovery Plan (DRP) — addresses how IT systems and infrastructure are recovered after a disruption. It is technology-oriented: which systems are recovered in what order, from what recovery site, using which backups. The DRP enables the BCP by restoring the technological foundation that normal operations depend on.

The two plans must be aligned: the RTO in the BCP ("we can sustain 4 hours without the payment system") must match the RTO in the DRP ("we can recover the payment system within 4 hours"). Misalignment — where the BCP assumes a faster recovery than the DRP can deliver — is a common and significant planning failure.

Testing BC/DR Plans

An untested BC/DR plan is a hypothesis, not a plan. Testing reveals: assumptions that don't hold (the backup server is sized for 10% of the production load, not 100%), dependencies that were not documented (the payment system depends on an LDAP server that is not in the DR scope), and human capability gaps (the team has never executed the failover procedure under realistic time pressure).

• Document review / desk-check — the team reads through the plan and identifies gaps. Lowest effort, lowest confidence.
• Tabletop exercise — a facilitated walkthrough of a scenario (ransomware outbreak, data centre fire, key personnel unavailable). The team talks through what they would do. Medium effort, moderate confidence.
• Simulation test — systems are failed (in a test environment) and the recovery procedure is executed. No actual disruption to production. High effort, high confidence for the technical recovery process.
• Full failover test — production is deliberately failed over to the DR site. Full confidence test; highest risk and effort. Required at least annually for critical systems with short RTOs.

Cyber Incidents as BC/DR Triggers

Ransomware has become the most common BC/DR activation trigger in enterprise environments — more common than natural disasters, power failures, or hardware failures. This has significant implications for BC/DR planning that traditional BC/DR frameworks did not anticipate:

• Backups may be infected — traditional BC/DR assumes the backup is clean. Ransomware with a 30–60 day dwell time may have encrypted or corrupted backups before the attack was detected. The DRP must include backup integrity verification before restoration.
• The recovery environment may be compromised — if the attacker still has presence in the environment, recovering systems from backup restores them to a compromised environment. Eradication must precede or accompany recovery.
• Legal hold requirements — unlike natural disasters, cyber incidents create evidence preservation requirements. The forensic investigation must not be destroyed by aggressive recovery actions.
• Communication complexity — cyber incidents involve regulatory notification (GDPR 72 hours), law enforcement considerations, and potential media interest simultaneously with recovery operations. The BCP communications section must address this complexity.

Security awareness is the most widely deployed — and most widely misunderstood — security control in enterprise environments. Annual compliance training that employees click through in 8 minutes while checking email does not reduce security risk. It satisfies an audit requirement. A genuine security awareness programme applies behaviour science to systematically change the decisions employees make when they encounter security risks — and it produces measurable reductions in phishing click rates, insider threat incidents, and human-enabled security failures.

Programme Design Principles

Effective security awareness programmes share several characteristics that distinguish them from compliance checkbox exercises:

• Behaviour-focused, not knowledge-focused — the goal is not for employees to know that phishing exists; it is for employees to behave differently when they encounter a phishing email. These are different objectives requiring different interventions.
• Continuous, not annual — annual training produces knowledge that decays within weeks. Continuous micro-learning, regular simulation exercises, and just-in-time training (triggered when an employee makes a risky decision) produces durable behaviour change.
• Role-specific content — the security risks facing a developer are different from those facing a finance team member or an executive. Generic training addressing all roles equally produces content that is irrelevant to everyone in particular.
• Positive reinforcement, not punitive — programmes that shame employees for failing phishing simulations or threaten disciplinary action for honest mistakes create cultures of secrecy around security incidents. People who fear reporting mistakes stop reporting them.

Phishing Simulation Programmes

Phishing simulations send realistic phishing emails to employees to measure click rates and credential submission rates, and to provide teachable moments to employees who click. Key design considerations:

• Baseline first — run an initial simulation to establish a click rate baseline before training intervention. Without a baseline you cannot measure improvement.
• Graduated difficulty — start with easy-to-identify phishing simulations to build confidence, then progressively increase realism. Targeting employees with extremely sophisticated spear-phishing simulations on day one produces demoralisation rather than learning.
• Immediate feedback — when an employee clicks a simulated phishing link, the landing page should provide immediate education about what they missed and why it was a phishing indicator. Delayed feedback (a training module days later) has significantly less impact.
• Track trends, not individuals — the programme should measure department-level and role-level trends; individual click rate tracking that is shared with managers creates the punitive culture that drives underreporting.

Role-Based Training Requirements

Measuring Culture

Measuring security culture requires multiple data sources rather than a single metric. A comprehensive culture measurement programme uses:

• Phishing simulation click rate trend — is the rate improving quarter-over-quarter?
• Voluntary incident reporting rate — are employees reporting suspicious emails and security concerns? Low reporting may indicate fear of consequences rather than absence of security incidents.
• Security survey results — periodic surveys measuring perceived importance of security, confidence in the security team's responsiveness, and whether security is seen as an enabler or obstacle.
• Security helpdesk ticket trends — employees asking security questions are engaged. A declining question volume may indicate security questions are being answered without going through official channels.
• Time to report incidents — the faster employees report suspected incidents, the more security-aware the culture.

Insider Threat Awareness as a Governance Control

Insider threat awareness has two components: training employees to recognise and report concerning behaviour in colleagues (the "see something, say something" approach), and training employees themselves on acceptable use — making the boundaries clear so that inadvertent insider violations are minimised.

Research consistently shows that most insider threats are not malicious — they are negligent. Employees who share confidential files with personal cloud storage for convenience, who forward work emails to personal accounts before holiday, or who provide credentials to a colleague so they can cover during an absence are not malicious insiders. They are employees who have not been clearly educated about the risks of those behaviours. Clear, specific, regularly reinforced training on data handling, access management, and communication security reduces this inadvertent insider exposure.

Security metrics are the mechanism by which the GRC programme demonstrates its value, communicates risk posture, and drives organisational decisions. Done well, they translate the technical complexity of security into the business language that executives and boards require. Done poorly, they provide a false sense of assurance through activity metrics ("we ran 5,000 phishing simulations this year") that measure effort without measuring outcomes.

The Four Categories of Security Metrics

1. Activity metrics — what the security team is doing: number of vulnerabilities scanned, number of training completions, number of incidents investigated. These are the easiest to measure and the least informative about security outcomes. An organisation that runs continuous vulnerability scans but remediates nothing is not more secure than one that scans quarterly and remediates everything.
2. Coverage metrics — what proportion of the environment is protected: percentage of endpoints with EDR deployed, percentage of users with MFA enabled, percentage of critical vulnerabilities remediated within SLA. More useful than activity metrics because they reveal gaps in control deployment.
3. Lagging indicators — outcomes that have already been achieved or failed: number of successful breaches, number of regulatory penalties, MTTD and MTTR for incidents. These are the ultimate proof of security programme effectiveness but are too slow to drive real-time management decisions.
4. Leading indicators — predictors of future outcomes: trend in open critical vulnerabilities, trend in phishing click rate, trend in patch coverage by system criticality. These are the most valuable metrics for management because they indicate the direction of travel before an incident occurs.

Board-Level Security Reporting

The board's security reporting needs are fundamentally different from what the security team tracks internally. Boards do not need to know about individual CVEs, specific firewall rules, or SIEM detection rates. They need to understand: what is the current risk level relative to appetite, what significant incidents occurred and what was the business impact, is the security programme improving or declining, and what decisions or resources are required from the board?

Effective board security reporting:

• 1-page executive summary — top 3 risks, current risk level (RAG status — Red/Amber/Green), whether it has improved or worsened since the last report, and any decisions required from the board
• Trend data, not point-in-time — a single data point is meaningless; trends over 12–24 months show whether the programme is improving
• Business impact language — not "we detected 1,200 phishing attempts" but "we blocked a campaign targeting finance team members that is consistent with BEC fraud attempts in our sector"
• Comparison against peers — boards understand competitive context; comparing your security metrics against sector benchmarks is more meaningful than absolute numbers

Key Security KPI Examples

Communicating Bad News to Leadership

Security practitioners are sometimes reluctant to report bad news — declining metrics, significant incidents, or compliance failures — because they anticipate negative reactions or fear for their careers. This reluctance is the most dangerous pattern in security reporting. Boards and executives who receive optimistic security reports make resource allocation decisions based on false assurance. When reality diverges sharply from the reported picture, the damage is greater both to security outcomes and to the security team's credibility.

Principles for communicating bad news effectively:

• Facts first, context second — state the issue clearly before explaining the reasons for it. "Our critical patch SLA compliance dropped to 68% this quarter" followed by the context (tool migration, resource constraints) is credible. Burying the number in context sounds defensive.
• Come with a plan — bad news delivered with a remediation plan is a management communication; bad news delivered without one is just bad news. The plan must be realistic.
• Frame in business terms — "this increases our exposure to ransomware-style attacks targeting unpatched systems, which account for 40% of breaches in our sector" is more actionable than "our patch compliance is low."
• Normalise the conversation — boards that only hear good news have been conditioned to expect it. Regular, honest reporting that includes both positive trends and challenges creates a more realistic and productive governance relationship.

The GRC tools market has grown significantly, driven by the compliance burden on technology companies and the maturation of the GRC discipline. Selecting and implementing the right tools at the right stage of programme maturity can dramatically accelerate compliance achievement and reduce ongoing maintenance burden. Selecting the wrong tools — or selecting the right tools at the wrong maturity level — produces expensive shelfware and frustrated teams.

The GRC Platform Landscape

GRC platforms span a wide range from enterprise-grade, highly configurable platforms to automated compliance tools designed for fast-growing technology companies:

What GRC Platforms Actually Do

The core capabilities that GRC platforms provide:

• Control library — a centralised catalogue of all controls the organisation has implemented, mapped to multiple framework requirements simultaneously. Edit the control once; all framework mappings update automatically.
• Automated evidence collection — API integrations with AWS, GCP, Azure, GitHub, Okta, GSuite, Jira, and hundreds of other systems continuously pull evidence of control effectiveness: user access lists, MFA configuration status, patch levels, backup test records.
• Risk register — structured risk tracking with ownership, treatment status, and residual risk scoring.
• Policy management — policy lifecycle management: creation, review, approval, distribution, attestation tracking. Employees attest that they have read and understood policies; the platform records and reports on attestation completion.
• Vendor risk management — vendor questionnaire distribution, response tracking, assessment storage, and risk scoring.
• Audit management — organise evidence by audit request, track auditor queries, manage findings to closure.
• Compliance dashboard — real-time view of control effectiveness and compliance posture across all applicable frameworks.

When Platforms Add Value vs Spreadsheets

The maturity threshold for a GRC platform investment is roughly: when the overhead of managing compliance evidence manually (collecting it, organising it by control, maintaining it as systems change) exceeds the cost of the platform and its implementation. For a 50-person company pursuing their first SOC 2 with a single engineer managing compliance, a spreadsheet with an automated compliance tool (Vanta, Drata) is the right answer. For a 500-person company maintaining SOC 2, ISO 27001, HIPAA, and PCI-DSS with a three-person GRC team, a properly implemented GRC platform pays for itself in reduced audit preparation time within the first year.

Signs you have outgrown spreadsheets: auditors are requesting evidence you cannot locate; different team members have different versions of the control library; evidence review before audits takes more than two weeks; you are managing more than two compliance frameworks simultaneously.

Integrating GRC with Engineering Tools

The most effective GRC programmes integrate with the tools where engineering work actually happens — rather than requiring engineers to manually attest in a separate system that they did not connect to their workflow:

• GitHub / GitLab — pull evidence of code review approvals, branch protection policies, and commit signing directly from version control
• Jira / Linear — pull evidence of vulnerability remediation tickets, change management approvals, and security review gates
• AWS Config / Azure Policy / GCP Security Command Centre — continuously verify cloud infrastructure configuration against security baselines; evidence of compliance is machine-generated and always current
• HR systems — pull evidence of employee onboarding security training completion and access provisioning workflow

Programme Management Discipline

GRC programmes fail through poor programme management as often as through insufficient security controls. The discipline required:

• Milestone tracking — ISO 27001 certification in 12 months requires a project plan with monthly milestones, owners, and escalation triggers for slippage. Vague goals ("improve security") produce vague progress.
• Stakeholder management — GRC work involves HR, Legal, IT, Finance, and business units. Managing these stakeholders' involvement, communicating expectations, and escalating non-responsiveness requires active relationship management.
• Risk tolerance for the programme itself — GRC programmes have their own risks: key person dependency (the entire ISO 27001 programme lives in one person's head), tool dependency (a GRC platform migration creates temporary compliance blind spots), and regulatory change (a new regulation requires rapid programme adaptation).

Everything in this module converges here. Building a security programme is the integrated application of governance, risk management, compliance, technical security, and organisational leadership. It is the work that separates a collection of security activities from a coherent programme with direction, accountability, and measurable outcomes. This chapter addresses how to build that programme — from initial assessment through multi-year roadmap to the certifications that validate GRC expertise.

Programme Maturity Assessment

Before building a roadmap, assess where the programme currently stands. A maturity assessment uses a framework (NIST CSF, CIS Controls, or a proprietary maturity model) to score the current state of each security domain against a defined maturity scale. The output is a capability heat map showing which areas are mature (and require only maintenance investment) and which are immature (and require development investment).

Common starting points for maturity assessments: many organisations find themselves mature in areas that have had compliance or audit attention (access management, vulnerability management) and immature in areas that have not (threat modelling, detection engineering, third-party risk). The maturity assessment prevents the common failure mode of investing heavily in already-mature areas because they are familiar, while neglecting genuine gaps.

The Security Roadmap

A security roadmap is a multi-year plan that translates the maturity assessment into a sequenced investment plan. Effective roadmaps have three characteristics that distinguish them from wish lists:

1. Prioritised by risk and business impact — not by what is easiest, most interesting, or what the team is already working on. Items are ordered by the reduction in risk they provide relative to their cost.
2. Sequenced for dependency — some security improvements are prerequisites for others. A SOC that builds detection rules before deploying Sysmon to generate the events the rules depend on is building on sand. The roadmap must reflect these dependencies.
3. Connected to business objectives — a roadmap that shows only security outcomes ("deploy EDR to 100% of endpoints") will not secure budget as reliably as one that connects those outcomes to business objectives ("reduce the likelihood of a ransomware outbreak that would disrupt manufacturing operations").

Securing Executive Sponsorship and Budget

Security investment competes with every other organisational priority for budget. Securing sponsorship and budget requires speaking the language of business risk, not technical security:

• Quantify risk in financial terms — a FAIR analysis showing that the proposed control investment of £500K reduces expected annualised loss from £3.2M to £800K is a compelling business case. "We need EDR because attackers are getting more sophisticated" is not.
• Reference regulatory obligations — "This investment is required to maintain PCI-DSS compliance. Non-compliance exposes us to £X in card brand fines and potential loss of card acceptance rights" creates urgency that a purely risk-based case sometimes does not.
• Tie to peer and industry incidents — when a competitor or sector peer suffers a significant breach, the risk becomes concrete and proximate for leadership. Use current threat intelligence to connect your budget request to real, recent events.
• Demonstrate programme momentum — executives are more willing to invest in a programme with visible progress and credible leadership than in one that appears to be asking for resources without prior accountability for past investments.

Why Governance Without Engineering Is Theatre

A security programme that produces excellent policies, risk registers, compliance reports, and executive dashboards — but whose technical controls are immature or absent — is compliance theatre. It satisfies auditors who review documentation; it does not stop attackers who probe systems. The GRC function depends on the technical security function to implement the controls that GRC has specified, monitored, and reported on. Without that implementation, GRC outputs are fiction.

Conversely, engineering without governance is ungoverned risk. Excellent technical security teams that operate without a risk framework, without executive visibility, and without regulatory awareness may invest in the wrong controls, fail to address compliance obligations, and lack the organisational authority to enforce their requirements on business units. The integration of GRC and technical security is not a soft management preference — it is a functional requirement for a programme that works.

Career Paths and Certifications