1. Introduction — What GRC Is and Why It Exists

Governance, Risk, and Compliance (GRC) is the integrated discipline through which an organisation directs itself toward its objectives (governance), manages the uncertainty that threatens those objectives (risk), and conforms to the obligations placed upon it (compliance). The word that matters most is integrated. Run separately, these three functions duplicate work, contradict each other, and leave gaps; run as one operating model, each strengthens the others. The auditor sits outside all three and independently confirms that the system actually works.

Before GRC emerged as a named discipline, large organisations ran governance in the boardroom, risk in a treasury or insurance function, and compliance in legal — three silos that rarely shared a vocabulary. A risk the security team tracked might never reach the board; a control the compliance team relied on might have quietly stopped working. The 2000s wave of corporate scandals and the regulation that followed (Sarbanes-Oxley in the US, Basel in banking, and later GDPR and India's DPDPA) forced these silos together: regulators began demanding evidence that leadership knew its risks and could prove its controls. GRC is the response — a single chain of accountability from the boardroom to the engineer operating a control.

The mental model to carry through this entire series

Objective → Risk → Control → Evidence → Assurance. You have a business objective. Risks threaten it. Controls reduce those risks. Evidence proves the controls operate. Assurance (audit) independently confirms the evidence. Every framework you will study — ISO 27001, SOC 2, GDPR, DPDPA — is a different vocabulary laid over this same five-link chain. If a control links to no objective or risk, it is waste; cut it. If a control produces no evidence, it will fail every audit, no matter how well intentioned.

1.1 GRC versus ERM versus IRM — precise distinctions

These terms are used loosely in the market, and using them loosely in front of a client signals inexperience. Learn the distinctions exactly.

GRC is the day-to-day integrated operating model spanning governance, risk, and compliance. It is broad and operational.
ERM (Enterprise Risk Management) is the firm-wide view of ALL risk categories — strategic, financial, operational, hazard, and cyber — considered together so leadership can make portfolio-level decisions. The reference frameworks are COSO ERM (2017) and ISO 31000 (2018). Information-security risk is one slice of ERM.
IRM (Integrated Risk Management) is Gartner's evolution of the GRC label, stressing technology-enabled, near-real-time, risk-aware decision-making rather than periodic compliance checklists.

How they nest: ERM is the widest lens (all enterprise risk). GRC is the operating model that makes governance, risk, and compliance work together. When you implement ISO 27001 you are performing ERM scoped to information security, executed through a GRC operating model, and proven through audit. Holding these relationships in your head lets you place any client request in the right layer.

1.2 The OCEG GRC Capability Model and “principled performance”

OCEG (the body that coined “GRC”) frames the goal as

“principled performance” — reliably achieving objectives while addressing uncertainty and acting with integrity. Its Capability Model organises GRC into four components you will recognise as a continuous loop:

LEARN — understand the context, culture, stakeholders, and objectives.
ALIGN — set strategy, objectives, and risk appetite; align actions and resources to them.
PERFORM — implement controls, run operations, and respond to events.
REVIEW — monitor, audit, and improve.

If that loop looks like Plan-Do-Check-Act, it is — every management-system standard in this series runs on the same engine of continual improvement.

1.3 The business case — why organisations fund GRC

A practitioner must be able to justify GRC in the language of the business, not of auditors. The arguments that win budget:

Avoided loss: fewer and smaller incidents, breaches, fines, and outages — quantifiable with the risk-quantification methods in Section 4.
Revenue enablement: certifications and attestations (ISO 27001, SOC 2) are gate-keepers to enterprise and government contracts. GRC directly unlocks deals.
Efficiency: one control mapped to many frameworks eliminates duplicated effort across audits.
Defensibility: when something goes wrong, documented governance and risk decisions limit legal liability and reputational damage — “we assessed this risk and treated it reasonably” is a defence; silence is not.
Better decisions: leadership steering with a clear, current view of risk makes faster, safer strategic choices.

1.4 The GRC maturity model

Use this to position any client and to set a realistic improvement target. Maturity is not about buying tools; it is about how repeatable and measured the organisation's behaviour is.

Level	Name	Characteristics	Typical signs
1	Initial / Ad hoc	Reactive, undocumented, person-dependent	Spreadsheets, firefighting, no owner
2	Managed	Some policies exist; execution inconsistent	Policies written but not followed
3	Defined	Documented, repeatable processes org-wide	Standard procedures, named owners
4	Quantitatively managed	Metrics-driven; risk measured in numbers	KRIs, dashboards, trend analysis
5	Optimising	Continuous improvement; risk informs strategy	Risk-adjusted decisions at board level

Practical use: most SMEs sit at Level 1–2. A realistic first engagement moves them to a solid Level 3 (documented, repeatable, owned). Chasing Level 5 prematurely wastes money — target the maturity the business risk justifies.

2. Governance in Depth

Governance is the system of direction and oversight: it answers who decides, who is accountable, how much risk the organisation will accept, and how performance against objectives is measured. Without governance, risk and compliance work has no authority and no consistency — controls drift, exceptions multiply, and no one owns the outcome.

2.1 Corporate governance principles

Modern governance rests on a few principles that recur in every code (the UK Corporate Governance Code, OECD principles, India's Companies Act and SEBI LODR):

Accountability — every objective, risk, and control has a single named owner. “The team” is not an owner.
Transparency — decisions, risks, and performance are visible to those who need them, including the board.
Responsibility — roles and authorities are defined; people act within them.
Fairness — stakeholders' interests are balanced.
Independence — oversight (audit, risk) is structurally separate from the operations it oversees.

2.2 Governance structures — who sits where and does what

You must be able to describe a governance structure to a board and to draw the reporting lines. The bodies and their cadence:

Body / role	Responsibility in GRC	Reports to	Cadence
Board of Directors	Ultimate accountability; approves risk appetite & strategy	Shareholders	Quarterly
Audit Committee	Oversees internal & external audit, controls, financial integrity	Board	Quarterly
Risk Committee	Owns risk framework; reviews appetite breaches	Board	Monthly/Qtr
CEO / Executive	Sets tone; resources the program	Board	Continuous
CISO	Runs information-security risk & controls	CEO/CIO/CRO	Continuous
CRO	Owns enterprise risk framework (2nd line)	CEO/Board	Continuous
DPO	Privacy compliance & advice (independent)	Top mgmt	Continuous
Control owners	Operate & evidence specific controls (1st line)	Line mgmt	Daily/Weekly

Why the committee structure matters: the audit committee exists so that internal audit can report bad news about management without management filtering it. If internal audit reports to the CFO it audits, its independence is compromised — a governance defect an external assessor will flag.

2.3 The policy management lifecycle

Policy is how governance intent becomes binding rules. A mature organisation manages policy as a lifecycle, not a one-time drafting exercise:

Develop — draft against a requirement (a risk, a law, a framework control).
Review — stakeholders (legal, IT, HR) comment.
Approve — the appropriate authority signs and dates it.
Communicate — publish; require acknowledgement; train.
Enforce — controls and consequences make it real.
Review & retire — re-approve on a schedule (usually annually); retire when obsolete.

The document hierarchy, with worked examples

Policy — high-level intent, board-approved, stable. Example: “SRXLABS protects the confidentiality, integrity, and availability of all information assets.”
Standard — mandatory, measurable rule that enforces the policy. Example: “All user accounts with access to production must use phishing-resistant multi-factor authentication.”
Procedure — the exact, repeatable steps. Example: “To grant production access: (1) raise a ticket; (2) line-manager approves; (3) IT provisions least-privilege role; (4) access auto-expires after 90 days.”
Guideline / baseline — recommended practice or hardening config (e.g., the CIS benchmark for a given OS). Not mandatory but advisory.

The single most common audit failure

A beautifully written policy that nobody follows because no procedure operationalises it and no evidence accumulates. A policy without a procedure and records is a “paper control” — it fails the audit on operating effectiveness. Every policy you write must be paired with a procedure and a defined place where evidence is generated automatically (a ticket queue, a log, a report).

2.4 Segregation of Duties (SoD)

SoD splits a sensitive process so that no single person can complete it alone, preventing both error and fraud. The classic example is payments: the person who creates a vendor must not be the person who approves payment to it; otherwise they can invent a fake vendor and pay themselves. In IT, the developer who writes code should not be the one who approves and deploys it to production unchecked.

Detect SoD conflicts by building an access-vs-duties matrix and flagging any individual holding two conflicting capabilities.
When SoD is impractical (a 5-person company), use a compensating control: independent after-the-fact review of the sensitive actions, logged and signed.

2.5 Risk appetite, tolerance, and capacity — a distinction clients always blur

Risk appetite — the amount and type of risk the organisation is willing to pursue to meet objectives, stated broadly. Example: “We will accept moderate availability risk to ship quickly, but near-zero risk to customer-data confidentiality.”
Risk tolerance — the acceptable variation around a specific objective, stated measurably. Example: “Unplanned downtime must not exceed 4 hours per quarter.”
Risk capacity — the maximum risk the organisation could absorb before it fails (a hard ceiling set by finances/regulation). Appetite should always sit below capacity.

A usable risk appetite statement (copy the shape)

“SRXLABS will not accept any residual risk rated High (≥13 on a 5×5 scale) affecting customer data. Medium residual risks (7–12) require a documented, time-bound treatment plan owned by a named manager. Low residual risks (≤6) may be formally accepted by the relevant control owner. Any breach of these limits is escalated to the Risk Committee within 5 business days.” That single paragraph drives every treatment decision in the risk register.

2.6 The Three Lines Model (IIA, 2020 update)

This is the governance model every auditor expects you to know cold. It separates who owns risk from who oversees it from who independently assures it. The 2020 update renamed it from “Three Lines of Defence” to “The Three Lines Model” and stressed collaboration over rigid walls.

First line — own and manage risk: operational management and staff who run the processes and operate the controls directly (the engineers, the ops team, the developers).
Second line — oversee and advise: risk and compliance functions that set the frameworks, provide expertise, monitor, and challenge the first line (the GRC team, CISO, CRO, DPO).
Third line — independent assurance: internal audit, structurally independent of the first two, reporting to the audit committee/board, giving objective assurance that the whole system works.

Worked example (a bank): loan officers approve loans within policy (1st line); the credit-risk function sets the limits and monitors adherence (2nd line); internal audit periodically tests whether the limits were actually respected and reports findings to the audit committee — not to the lending head it just audited (3rd line). The independence of the third line is what makes its assurance credible.

2.7 Governance frameworks worth naming

COBIT (ISACA) — governance and management of enterprise IT; separates governance (EDM: Evaluate, Direct, Monitor) from management. Common in IT-audit contexts.
ISO/IEC 38500 — corporate governance of IT (principles for the board).
COSO Internal Control – Integrated Framework — the five-component model (control environment, risk assessment, control activities, information & communication, monitoring) that underpins SOX and SOC 2's Common Criteria.

3. Risk Management — Concepts and Frameworks

Risk management is the disciplined process of finding what could stop you achieving your objectives, deciding how much of that uncertainty you will tolerate, and treating the rest. It is the analytical heart of GRC: governance sets the appetite, compliance is one source of risk, and audit checks that risks were handled — but risk management is where the actual thinking happens.

3.1 The vocabulary, defined precisely

Imprecise language here causes real errors. A vulnerability is not a risk; a threat is not a risk. Risk is the combination of a threat exploiting a vulnerability, expressed as likelihood times impact.

Term	Precise definition	Worked example
Asset	Something of value to protect	Customer database
Threat	A potential cause of an unwanted event	Ransomware operator
Threat actor	The entity behind the threat	Organised crime group
Vulnerability	A weakness a threat can exploit	Unpatched VPN (CVE)
Likelihood	Probability over a defined period	0.4 events/year
Impact	Magnitude of loss if it occurs	₹5 cr + 3-day outage
Risk	Likelihood × impact of a threat-vuln pair	Probable data breach via VPN
Inherent risk	Risk before any controls	5 × 5 = 25
Residual risk	Risk remaining after controls	2 × 4 = 8
Control	A measure that reduces risk	Patch + MFA + monitoring

3.2 ISO 31000:2018 — the international risk-management standard

ISO 31000 is principles-based and applies to any risk, not just cyber. It has three parts you should be able to recite: principles, framework, and process.

Principles (the 8 that make risk management effective)

Risk management should be integrated, structured & comprehensive, customised to context, inclusive of stakeholders, dynamic (responsive to change), based on the best available information, account for human and cultural factors, and be continually improved. The single most important is that it must create and protect value — risk management that doesn't help the organisation achieve objectives is bureaucracy.

Framework (the organisational scaffolding)

Leadership and commitment sit at the centre, surrounded by a cycle of integration, design, implementation, evaluation, and improvement of the risk-management arrangements. This is the governance wrapper that makes the process actually run.

Process (the operational steps — these are what you execute)

Communication & consultation — ongoing with stakeholders throughout (not a phase, a constant).
Scope, context & criteria — define what's in scope, the internal/external context, and the criteria for evaluating risk.
Risk identification — find the risks.
Risk analysis — understand likelihood and consequence.
Risk evaluation — compare against criteria/appetite and prioritise.
Risk treatment — select and implement responses.
Monitoring & review + recording & reporting — the steps beginners skip; risk is a living thing.

3.3 COSO ERM (2017) — the enterprise lens

Where ISO 31000 is a lean process, COSO ERM ties risk explicitly to strategy and performance. It organises enterprise risk management into five interrelated components (with 20 underlying principles):

Governance & culture — the board's risk oversight and the organisation's risk culture and values.
Strategy & objective-setting — risk appetite is set here and woven into strategy; you consider risk when choosing objectives.
Performance — identify, assess, prioritise, and respond to risks that affect achieving objectives.
Review & revision — assess how the ERM components are functioning and revise.
Information, communication & reporting — the connective tissue across all components.

ISO 31000 vs COSO ERM: ISO 31000 is concise, flexible, and applies to any risk — good for an operational risk programme. COSO ERM is heavier and strategy-centric — favoured by US-listed companies and finance functions. Many organisations use ISO 31000 for the process and borrow COSO's strategy linkage. Know both names and their flavour.

4. The Risk Process, Step by Step

4.1 Risk identification techniques

You cannot treat a risk you never found. Mature programmes use several complementary techniques rather than relying on one workshop:

Asset-based: list assets, then ask what threatens each (good for ISO 27001).
Scenario-based: imagine concrete adverse scenarios (“key engineer leaves and takes source code”) and work backwards.
Threat-intelligence-driven: use external feeds and MITRE ATT&CK to identify realistic attacker behaviours.
Brainstorming & Delphi: structured group elicitation; Delphi anonymises expert input across rounds to avoid groupthink.
Checklists & taxonomies: drive completeness against a known risk catalogue.
FMEA (Failure Mode & Effects Analysis): systematically examine how each component can fail and the effect — borrowed from engineering.
Bow-tie analysis: map a central risk event to its causes (left) and consequences (right), with preventive controls on the left and mitigative controls on the right — excellent for communicating to executives.

4.2 Risk analysis — qualitative

The starting point for most organisations. Rate likelihood and impact on defined scales (commonly 1–5), multiply, and plot on a heat map. The discipline is in defining the scales precisely so two assessors agree.

Likelihood scale	Meaning	Impact scale	Meaning
1 Rare	< once in 5 yrs	1 Insignificant	< ₹1 L
2 Unlikely	Once in 2–5 yrs	2 Minor	₹1–10 L
3 Possible	Once a year	3 Moderate	₹10–50 L
4 Likely	Few times a year	4 Major	₹50 L–5 cr
5 Almost certain	Monthly+	5 Severe	> ₹5 cr

Score bands: 1–6 Low (green, accept/monitor); 7–12 Medium (amber, treat on a plan); 13–25 High (red, treat urgently and escalate). Always define the scales in the document so the heat map is reproducible, not subjective.

4.3 Risk analysis — quantitative (the advanced layer that wins budget)

Qualitative “high/medium/low” cannot answer “how much should we spend?” Quantitative methods express risk in money, which boards understand. Learn both the classic SLE/ALE method and the modern FAIR model.

Classic method: SLE, ARO, ALE

SLE (Single Loss Expectancy) = Asset Value (AV) × Exposure Factor (EF)
ALE (Annualised Loss Expectancy) = SLE × ARO (Annual Rate of Occurrence)

Example — laptop theft:
  AV (device + data) = ₹2,00,000   EF = 0.6 (60% loss if it happens)
  SLE = 2,00,000 × 0.6 = ₹1,20,000
  ARO = 0.5 (one theft every two years)
  ALE = 1,20,000 × 0.5 = ₹60,000 per year

Decision: full-disk encryption + tracking @ ₹15,000/yr is justified
because the control costs far less than the ₹60,000 annual exposure.

Modern method: FAIR (Factor Analysis of Information Risk)

FAIR decomposes risk into measurable factors so you can defend the numbers. Risk = Loss Event Frequency (LEF) × Loss Magnitude (LM). LEF itself = Threat Event Frequency (TEF) × Vulnerability (the probability an attempt succeeds). Loss Magnitude splits into Primary Loss (direct) and Secondary Loss (fines, reputation, response).

Scenario: phishing -> business email compromise -> fraudulent wire.
  Threat Event Frequency (TEF)  = 12 attempts/year
  Vulnerability (success rate)  = 0.10
  LEF = 12 × 0.10 = 1.2 events/year
  Primary Loss   = ₹8,00,000 (the wire)
  Secondary Loss = ₹2,00,000 (response, legal, reputation)
  Loss Magnitude = ₹10,00,000
  ALE = LEF × LM = 1.2 × 10,00,000 = ₹12,00,000/year

Add MFA + payment call-back verification (₹1,50,000/yr):
  New Vulnerability = 0.02 -> LEF = 0.24 -> ALE = ₹2,40,000/year
  Risk reduced by ₹9,60,000 for ₹1,50,000 -> fund it.

Monte Carlo & Value at Risk — for mature programmes

Single point estimates hide uncertainty. Instead, model TEF, Vulnerability, and Loss as ranges (e.g., PERT or triangular distributions with min/most-likely/max), then simulate 10,000+ iterations. The output is a loss-exceedance curve: “there is a 10% chance annual loss exceeds ₹50 lakh.” That 90th-percentile figure is your cyber Value at Risk — exactly the language a CFO uses for financial risk. Tools: open FAIR-U training material, RiskLens-style platforms, or a spreadsheet with a Monte Carlo add-in.

Why quantification is the senior-consultant skill

Anyone can label phishing “High risk.” Saying “this ₹1.5 L control returns ₹9.6 L/yr of avoided loss, and cuts our cyber Value-at-Risk from ₹50 L to ₹15 L” gets budget approved in one meeting. The ability to move between qualitative speed and quantitative rigour is what separates a checklist-filler from a trusted advisor.

4.4 Risk evaluation and treatment

Evaluation compares analysed risk against the appetite/criteria to decide what needs treatment and in what order. Treatment then applies one of four responses — the “four T's”:

Treat / Mitigate (reduce): add or strengthen controls to lower likelihood or impact. The most common response. Example: patch + MFA + monitoring on the vulnerable VPN.
Transfer / Share: shift the financial consequence to a third party — cyber insurance, or outsourcing with contractual SLAs and indemnities. Note: you can transfer financial impact, but rarely accountability or reputational damage.
Terminate / Avoid: stop the activity that creates the risk. Example: decide not to store credit-card numbers at all, removing the entire PCI burden.
Tolerate / Accept: consciously retain the risk because it is within appetite or treatment would cost more than the exposure. Acceptance must be formal, documented, owned, and time-bound — never implicit.

Inherent → control → residual, made concrete

Inherent risk is the risk with no controls (5×5 = 25). You apply controls until residual risk falls below appetite (2×4 = 8, within a ≤12 appetite). Risk acceptance is always a decision about the residual, signed off by the risk owner. If residual still exceeds appetite after reasonable treatment, you escalate — you do not quietly accept it.

4.5 The risk register — your central artifact, fully specified

Every engagement revolves around a living risk register. A professional register has at least these fields:

Field	Example value
Risk ID	R-014
Risk statement	Internet-facing VPN with a known CVE is exploited for initial access
Category	Cyber / External
Threat / vulnerability	Ransomware actor / unpatched appliance
Owner	Head of IT
Inherent likelihood × impact	5 × 5 = 25 (High)
Existing controls	Perimeter firewall; basic logging
Residual likelihood × impact	2 × 4 = 8 (Medium)
Treatment decision	Mitigate: 14-day patch SLA + MFA + alerting
Target & due date	Residual ≤ 6 by 30 Jun 2026
Status	In progress (60%)
Last reviewed	2026-05-20

5. Monitoring, Metrics, and Risk Culture

5.1 KPIs versus KRIs

KPI (Key Performance Indicator) — measures how well something is performing now (e.g., “98% of systems patched within SLA”). Backward/present looking.
KRI (Key Risk Indicator) — a leading, predictive metric that signals risk is rising before it materialises (e.g., “number of overdue critical patches trending up for 3 weeks”). A KRI breaching its threshold should trigger action.

The art is choosing KRIs that genuinely predict loss events and setting thresholds (green/amber/red) that prompt timely action rather than alert fatigue.

5.2 A worked KRI dashboard

KRI	Green	Amber	Red
Critical patches overdue	0	1–3	> 3
Privileged accounts without MFA	0	1–2	> 2
Overdue access reviews	0	1	> 1
Phishing-simulation click rate	< 5%	5–10%	> 10%
Mean time to patch (critical)	< 7d	7–14d	> 14d
Open high-risk findings past due	0	1–2	> 2

5.3 Risk reporting

Different audiences need different views. The board wants a one-page heat map, top-5 risks, appetite breaches, and trend arrows. Management wants the full register with owners and due dates. Operations wants the specific controls and tasks. Tailoring the report to the audience is a core consulting skill — a board does not want a 200-line register, and an engineer does not want a heat map.

5.4 Risk culture — the factor that decides whether any of this works

The best framework fails in a culture that punishes bad news or rewards shortcuts. Signs of healthy risk culture: people report incidents and near-misses without fear; leaders visibly make risk-informed decisions; risk ownership is accepted, not dodged; and “tone at the top” is matched by “mood in the middle.” Measuring culture (surveys, near-miss reporting rates, time-to-report) is itself a maturity indicator.

6. Compliance Management

Compliance is conforming to the obligations placed on the organisation — laws, regulations, contractual commitments, and internal policy. The practitioner's job is to turn a sprawling, overlapping set of obligations into a managed programme with clear ownership and evidence, rather than a panic before each audit.

6.1 The regulatory landscape (global + India)

You must know which regimes touch a given client. A partial map:

Regime	Domain	Who it binds
GDPR	Privacy (EU)	Anyone handling EU residents' data
DPDPA 2023	Privacy (India)	Anyone handling Indian individuals' data
IT Act 2000 + rules	Cyber/India	All Indian entities (incl. CERT-In rules)
PCI DSS	Card data	Anyone storing/processing card payments
RBI / SEBI / IRDAI	Finance/India	Banks, NBFCs, markets, insurers
HIPAA	Health (US)	US healthcare & associates
SOX	Financial reporting (US)	US-listed companies
ISO 27001 / SOC 2	Voluntary assurance	Often contractually required

India specifics worth knowing: the CERT-In Directions (2022) impose strict incident-reporting timelines (notably reporting certain incidents within 6 hours) and logging-retention obligations — a live compliance item for Indian firms that SRXLABS clients frequently overlook.

6.2 Elements of a compliance programme

Obligations register: a catalogue of every applicable requirement, its source, the owner, and how it's met — the compliance equivalent of the risk register.
Mapping/crosswalk: link each obligation to the controls that satisfy it (one control often satisfies many).
Monitoring & testing: periodically confirm obligations are still met.
Regulatory-change management: watch for new/changed laws and feed them into the register — compliance is a moving target.
Training & attestation: staff know the rules and acknowledge them.
Reporting & escalation: breaches and gaps reach the right level quickly.

6.3 Third-party / vendor risk — a compliance and risk hotspot

Most modern breaches involve a supplier (recall Target via an HVAC vendor). Third-party risk management means: inventory vendors, tier them by the data/access they hold, assess each (security questionnaire + review of their SOC 2/ISO certificate), contract for security obligations and breach notification, and monitor continuously. NIST CSF 2.0 elevated this to its own focus (GV.SC). For SRXLABS, vendor risk assessments are a sellable service in themselves.

7. Control Frameworks in Depth

Controls are the layer auditors actually test. A control is any measure — administrative, technical, or physical — that reduces risk by lowering likelihood or impact. Fluency in classifying and selecting controls is core.

7.1 Control classification (two axes)

By function	By nature	Example
Preventive	Technical	MFA, firewall rule, input validation
Detective	Technical	SIEM alert, file-integrity monitoring
Corrective	Technical	Auto-isolate host, restore from backup
Preventive	Administrative	Policy, training, segregation of duties
Detective	Administrative	Access review, log review, internal audit
Preventive	Physical	Badge access, mantrap, locks
Deterrent	Any	Warning banners, visible CCTV
Compensating	Any	An alternative when the primary isn't feasible

Defence in depth means layering preventive, detective, and corrective controls so that if one fails another catches the event — you don't rely on a single control for a serious risk.

7.2 NIST Cybersecurity Framework 2.0 (2024) — in full

CSF 2.0 organises a whole security programme around six Functions. Version 2.0's headline change was adding GOVERN as the central function that wraps the other five — a direct nod to the GRC mindset.

GOVERN (GV): establish and monitor the cybersecurity risk-management strategy, expectations, roles, policy, and — importantly — supply-chain risk (GV.SC).
IDENTIFY (ID): asset management, risk assessment, and improvement — know your assets, data, suppliers, and risks.
PROTECT (PR): identity management & access control (PR.AA), awareness & training (PR.AT), data security (PR.DS), platform security, technology resilience.
DETECT (DE): continuous monitoring (DE.CM) and adverse-event analysis.
RESPOND (RS): incident management, analysis, mitigation, and reporting.
RECOVER (RC): recovery plan execution and communications.

Each Function contains Categories (e.g., ID.AM = Asset Management) and Subcategories (specific outcomes). CSF also defines Implementation Tiers (1 Partial → 4 Adaptive) describing rigour, and Profiles (Current vs Target) used to plan a roadmap. A gap analysis is literally Current Profile vs Target Profile.

Worked CSF gap analysis

Category	Current Tier	Target Tier	Gap action
ID.AM (Asset Mgmt)	1 Partial	3 Repeatable	Deploy discovery + CMDB
PR.AA (Access)	2 Risk-informed	3 Repeatable	Enforce MFA; quarterly reviews
DE.CM (Monitoring)	1 Partial	3 Repeatable	Stand up SIEM + alerting
RS.MA (Response)	1 Partial	3 Repeatable	Write & test IR plan

7.3 CIS Critical Security Controls v8 — the prioritised action list

Where CSF is outcome-oriented, the CIS Controls (18 controls, grouped into Implementation Groups IG1–IG3 by organisation size/risk) give a concrete, prioritised to-do list. The first handful eliminate the majority of common attacks:

1–2 Inventory of enterprise assets & software — you can't protect what you don't know exists.
3 Data protection · 4 Secure configuration · 5 Account management · 6 Access control management.
7 Continuous vulnerability management · 8 Audit log management · 9 Email/web protections · 10 Malware defences.
11 Data recovery · 12 Network infrastructure · 13 Network monitoring · 14 Security awareness training.
15 Service-provider management · 16 Application software security · 17 Incident response · 18 Penetration testing.

Practical use: for an SME, IG1 (basic cyber hygiene across all 18) is a realistic, defensible baseline you can implement and audit against quickly.

7.4 Other catalogues to name

NIST SP 800-53 — a large control catalogue (20 families: AC, AU, CM, IR, SC, etc.) used by US federal systems; 800-171 is the trimmed version for contractors.
ISO 27002:2022 — the implementation guidance for ISO 27001's 93 Annex A controls (covered fully in Module 2).

7.5 The control crosswalk — build once, satisfy many

The highest-leverage artifact a GRC practitioner maintains: one master control set mapped to every framework the organisation must meet, so a single well-run control answers multiple audits.

Control	ISO 27001	SOC 2	NIST CSF	CIS v8	DPDPA
Quarterly access review	A.5.18	CC6.2/6.3	PR.AA	6	Safeguards
MFA on all access	A.8.5	CC6.1	PR.AA	6	Safeguards
Encryption in transit/rest	A.8.24	CC6.7	PR.DS	3	Safeguards
Security awareness training	A.6.3	CC1.4	PR.AT	14	—
Incident response plan	A.5.24	CC7.3/7.4	RS.MA	17	Breach duty
Audit logging & review	A.8.15	CC7.2	DE.CM	8	Safeguards

8. Audit — Fundamentals and Planning

Audit is independent verification that controls exist and operate. For SRXLABS this is both a service you sell and the experience your clients face when getting certified. Master it from both chairs.

8.1 Types of audit

Type	Who performs it	Example
First-party (internal)	The organisation on itself	Internal ISO 27001 audit before cert
Second-party	A customer audits its supplier	A bank audits its SaaS vendor
Third-party (external)	Independent body / CPA	BSI certifies ISO 27001; a CPA issues SOC 2

8.2 Audit standards & professional bodies

IIA IPPF — the Institute of Internal Auditors' International Professional Practices Framework (standards for internal audit independence, objectivity, competence).
ISACA ITAF — the IT Assurance Framework; CISA is the headline IT-audit certification.
AICPA SSAE 18 — the attestation standard SOC reports are performed under.

8.3 Risk-based audit planning

Mature audit functions don't audit everything equally; they focus effort where risk is highest. An audit universe (all auditable entities) is risk-ranked, and the annual audit plan allocates time to the riskiest areas. Each engagement then gets a scope, objectives, criteria (the standard you audit against), and a timeline agreed in an engagement letter.

8.4 The audit lifecycle

Planning & scoping — define scope, objectives, criteria, risk, and resources.
Fieldwork — gather evidence via inquiry, observation, inspection, re-performance, and CAATs.
Testing — evaluate control design and operating effectiveness.
Findings — document gaps with evidence, rated by severity.
Reporting — issue the report; management responds.
Follow-up — verify remediation actually happened.

9. Audit — Evidence, Testing, and Sampling

9.1 Evidence-gathering techniques

Auditors live by evidence; a claim without it is worthless. The five techniques, in roughly ascending reliability:

Inquiry: asking staff. Weakest alone — always corroborate.
Observation: watching a process happen (e.g., watching a badge-access door).
Inspection: examining documents/records/configs (a policy, a log, a firewall ruleset).
Re-performance: the auditor independently re-runs the control (re-calculates, re-checks an access list) — strong evidence.
CAATs (Computer-Assisted Audit Techniques): scripts/queries that test 100% of a population rather than a sample (e.g., query all users for any without MFA). The future of audit.

Strong evidence is sufficient (enough), appropriate (relevant + reliable), independent (not produced solely by the auditee on request), and contemporaneous (created when the control ran, not the night before the audit).

9.2 Design vs operating effectiveness — the central distinction

Design effectiveness: if operated as described, would the control actually address the risk? Tested by inspection and walkthrough at a point in time.
Operating effectiveness: did the control actually operate consistently across the whole period? Tested by sampling over time.

The classic exam trap

A SOC 2 Type I tests design at a point in time; a SOC 2 Type II tests operating effectiveness over a period. A control can be perfectly designed yet fail operating-effectiveness testing because it wasn't actually run — e.g., the access-review policy is excellent, but reviews were skipped for two quarters. Design pass, operating fail.

9.3 Sampling — the numbers and the logic

Auditors rarely test 100% (unless using CAATs); they sample. You must understand populations, sample sizes, and exceptions so your evidence survives scrutiny.

Population: all instances of the control operating in the period (e.g., all 312 access changes).
Statistical vs judgmental sampling: statistical uses random selection for projectable results; judgmental targets higher-risk items based on auditor judgement.

Control frequency	Typical sample size
Many times per day	25–40
Daily	25
Weekly	15
Monthly	5
Quarterly	2
Annually	1

Exceptions: any sampled item that fails. One exception triggers an isolated-vs-systemic assessment. If the root cause suggests the whole population is affected, a single exception becomes a control failure. This is precisely why automated controls (clean populations) beat manual ones.

10. Audit — Findings, Root Cause, and Reporting

10.1 Writing a finding — the 5 C's

Every professional finding follows the same structure so a reader can act on it without the auditor present:

Finding F-007 — Terminated-user access not revoked within SLA

Criteria: Policy SEC-STD-04 requires access revocation within 24 hours of termination.

Condition: 2 of 25 sampled terminations (8%) retained VPN access for 6 and 9 days.

Cause: Offboarding relies on a manual HR email to IT with no ticket, deadline, or alert.

Effect (risk): Former staff could access internal systems; data-exfiltration and unauthorised-access exposure.

Recommendation: Integrate the HRIS with the identity provider to auto-disable accounts on termination; alert if not completed within 24h.

Rating: Medium. Management response: Accepted; SCIM auto-deprovisioning live by 30 Jun 2026 (owner: Head of IT).

10.2 Root-cause analysis

5 Whys: ask “why” iteratively until you reach the systemic cause, not the symptom. “Access wasn't revoked” → why? “IT wasn't told in time” → why? “no deadline on the handoff” → why? “the offboarding process has no enforced gate” — fix the gate, not the symptom.
Fishbone (Ishikawa) diagram: categorise possible causes (people, process, technology, environment) to structure the analysis.

10.3 Opinions, nonconformities, and CAPA

Attestation opinions: Unqualified (clean) / Qualified (specific exceptions) / Adverse (controls not effective) / Disclaimer (insufficient evidence).
ISO nonconformities: Major (a whole requirement missing/systemic — blocks certification) / Minor (isolated lapse — fix on a plan) / Observation (advice, not a failure).
CAPA (Corrective and Preventive Action): correction fixes the specific instance; corrective action removes the root cause to prevent recurrence; then you verify closure.

10.4 Reporting and follow-up

The audit report carries an executive summary (risk posture in business language), scope & methodology, detailed findings with evidence and ratings, and management responses with owners and dates. Follow-up audits then verify findings were genuinely closed — an unverified “fixed” is not closed. Continuous auditing (automated, ongoing testing via CAATs) is the modern direction, replacing point-in-time sampling for many controls.

11. Building a GRC Program — 90-Day Playbook

Days 1–10 — Mandate & scope: secure an executive sponsor, define scope, choose a primary framework (ISO 27001 or NIST CSF), and set the risk-appetite statement.
Days 11–25 — Discover: build the asset & data inventory and a system/dataflow diagram. You cannot protect or assess what you can't see.
Days 26–40 — Assess risk: run workshops, populate the risk register, score inherent risk, assign owners.
Days 41–55 — Design controls: map controls to risks (crosswalk), write policies/procedures, define each control's evidence source.
Days 56–75 — Implement & evidence: deploy controls; wire each to an automatic evidence source (tickets, logs, reports).
Days 76–85 — Operate & monitor: stand up KPIs/KRIs; begin the evidence trail.
Days 86–90 — Internal audit + management review: test a sample, fix gaps, report to leadership, plan the next cycle.

11.1 GRC tooling

Compliance automation: Vanta, Drata, Sprinto, Secureframe — auto-collect evidence and map controls; ideal for SOC 2 / ISO 27001.
Enterprise GRC/IRM: ServiceNow IRM, Archer, OneTrust, LogicGate, AuditBoard — for larger risk registers, workflows, and reporting.
Quantitative risk: FAIR-U / RiskLens-style tools or a Monte-Carlo spreadsheet.
Lean start: a well-structured spreadsheet register + a documented evidence repository is entirely valid for early-stage clients.

12. Templates Library (Use Verbatim)

12.1 Risk-acceptance memo

RISK ACCEPTANCE — R-022
Risk: Legacy reporting server cannot support MFA (vendor end-of-life).
Residual rating: Medium (9). Appetite: ≤ 12 for internal systems.
Compensating controls: network-isolated VLAN; jump-host-only access;
                       weekly log review; quarterly re-evaluation.
Accepted by: CISO          Date: 2026-05-20
Review date: 2026-11-20 (or on decommission, whichever is first).

12.2 Internal audit programme (excerpt)

Control	Test procedure	Sample	Evidence
Access reviews (A.5.18)	Inspect review records; reperform 1	2 of 4 qtrs	Signed review sheets
Change mgmt (CC8.1)	Inspect approvals; trace to deploy	25 changes	PRs + CI logs
Backups (A.8.13)	Inspect logs; confirm a restore test	Monthly	Restore-test record

12.3 Vendor risk assessment (mini)

Tier the vendor by data/access; request their SOC 2/ISO certificate; issue a security questionnaire; review encryption, access control, breach-notification terms; record residual risk and a re-assessment date.

12.4 BIA fields (for the continuity link)

Process · criticality · RTO (how fast to recover) · RPO (max data loss) · dependencies · minimum resources. A BIA drives your DR/BCP priorities and feeds availability risk.

13. Real-World Case Studies (GRC Failure Analysis)

Equifax (2017, ~147M records): an unpatched Apache Struts vulnerability — with a patch available for roughly two months — was exploited; an expired certificate then blinded detection for months. GRC failures: broken asset/patch inventory (ID), and detective controls that existed on paper but weren't operating (DE). The technology fix existed; governance and operating effectiveness did not.
Target (2013, ~40M cards): attackers entered through an HVAC vendor's stolen credentials, then moved laterally to point-of-sale systems. GRC failures: third-party/vendor risk management and network segmentation. Lesson — supplier risk (now CSF GV.SC) is squarely in scope.
Capital One (2019, ~100M records): a misconfigured web-application firewall plus an over-permissive IAM role let an attacker read cloud storage. GRC failures: cloud control design and least privilege — a governance and risk issue, not just an engineering bug.
SolarWinds (2020, supply chain): attackers compromised the build pipeline to ship malicious updates to thousands of customers. Lesson — software supply-chain integrity and third-party assurance are now board-level risks.

The recurring pattern: in almost every major breach the decisive failure was governance, inventory, third-party oversight, or untested response — exactly the things GRC governs. The exploit was often the least interesting part.

14. Hands-On Labs

Lab 1 — Quantify and decide (45 min)

A SaaS firm faces credential stuffing: 50,000 attempts/yr, 0.3% succeed, average loss per account takeover ₹40,000. Compute LEF and ALE. A bot-mitigation + MFA control costs ₹6,00,000/yr and cuts success to 0.02%. Recompute ALE and decide. (LEF before = 150; ALE = ₹60,00,000. After: LEF = 10; ALE = ₹4,00,000. Saves ₹56,00,000 for ₹6,00,000 — fund it.)

Lab 2 — Write a finding (30 min)

Backups exist but no restore has ever been tested. Write a finding using the 5 C's, assign a rating, run a 5-Whys to the root cause, and distinguish the correction from the corrective action.

Lab 3 — Build a mini risk register (60 min)

For SRXLABS, list 8 risks across cyber, people, vendor, and compliance. Score inherent L×I, name a control and owner, estimate residual, choose a treatment, and flag any residual above a ≤12 appetite.

Lab 4 — CSF gap analysis (45 min)

Pick three CSF categories (e.g., ID.AM, PR.AA, RS.MA). Rate Current vs Target tiers for a small company and define the concrete gap action for each. Produce a one-page roadmap.

Lab 5 — Build a crosswalk (30 min)

Take five controls you operate and map each to ISO 27001, SOC 2, NIST CSF, and DPDPA. This is the artifact that lets one control satisfy four audits.

15. Interview / Certification Q&A

Questions phrased the way CISA, CRISC, and ISO Lead Implementer exams (and client interviews) ask them.

Q: Inherent vs residual risk? A: Before vs after controls; you treat until residual is within appetite, then a named owner accepts the residual.
Q: When accept rather than mitigate? A: When residual is within appetite, or treatment cost exceeds the ALE; acceptance must be documented, owned, and time-bound.
Q: Difference between a policy, standard, and procedure? A: Intent (board-approved) / mandatory measurable rule / exact steps.
Q: What is a compensating control? A: An alternative giving comparable risk reduction when the primary control isn't feasible (e.g., isolation + monitoring when MFA can't be applied).
Q: ISO 31000 process steps? A: Context → identify → analyse → evaluate → treat → monitor/review, with communication throughout.
Q: COSO ERM vs ISO 31000? A: COSO is strategy-centric and heavier (US-listed); ISO 31000 is lean and applies to any risk.
Q: Design vs operating effectiveness? A: Is the control built right (point-in-time) vs did it run consistently (over a period, sampled).
Q: Sample size for a daily control? A: ~25, risk-adjusted; one exception prompts an isolated-vs-systemic assessment.
Q: Explain the Three Lines Model. A: Own (1st) / oversee (2nd) / independently assure (3rd, reporting to the audit committee).
Q: KPI vs KRI? A: Performance achieved vs a leading indicator that risk is rising.
Q: Six NIST CSF 2.0 functions? A: Govern, Identify, Protect, Detect, Respond, Recover — Govern was added in 2.0.
Q: The 5 C's of a finding? A: Criteria, Condition, Cause, Effect, Recommendation.

16. Glossary, Certifications, and Next Steps

16.1 Glossary

ISMS / SoA / RTP: Information Security Management System / Statement of Applicability / Risk Treatment Plan.
ERM / IRM: Enterprise / Integrated Risk Management.
ALE / SLE / ARO / EF: Annualised Loss Expectancy / Single Loss Expectancy / Annual Rate of Occurrence / Exposure Factor.
LEF / TEF / LM: Loss Event Frequency / Threat Event Frequency / Loss Magnitude (FAIR terms).
BIA / RTO / RPO: Business Impact Analysis / Recovery Time Objective / Recovery Point Objective.
DPIA / CAPA / SoD: Data Protection Impact Assessment / Corrective & Preventive Action / Segregation of Duties.
KRI / KPI / CAAT: Key Risk Indicator / Key Performance Indicator / Computer-Assisted Audit Technique.

16.2 Certifications that map to this module

Governance/risk: CRISC (risk), CGEIT (governance).
Audit: CISA (IT audit), CIA (internal audit).
Security management: CISM, CISSP.
Implementer: ISO 27001 Lead Implementer / Lead Auditor (your next module).

16.3 One-line cheat sheet

Objective → Risk → Control → Evidence → Assurance. ALE = SLE × ARO. FAIR: Risk = LEF × LM. Treat = Mitigate/Transfer/Avoid/Accept. Findings = Criteria/Condition/Cause/Effect/Recommendation. CSF = GV-ID-PR-DE-RS-RC. Three Lines = Own/Oversee/Assure.

Mastery check — you've mastered this module if you can…

1. Place GRC, ERM, and IRM correctly and state the GRC maturity levels.

2. Run the full ISO 31000 process and choose between qualitative and quantitative analysis.

3. Quantify a risk with both ALE and FAIR, and justify a control on ROI / Value-at-Risk.

4. Build a risk register row and a risk-acceptance memo with compensating controls.

5. Explain control types and build a crosswalk mapping one control to four frameworks.

6. Run a NIST CSF current-vs-target gap analysis.

7. Execute the audit lifecycle: plan, sample, test design vs operating, and write a 5-C's finding.

8. Take a nonconformity from root cause (5 Whys) through correction, corrective action, and verification.