Security Governance, Risk & Assurance

#Ethics, Accountability and the Governance Document Stack

#What is this?

Governance is the system of decisions and accountability that sits above the technical controls: who decides, what the rules are, and who answers when they are broken. Ethics is the set of principles security professionals are held to when no rule covers the situation.

#Why it matters

Technical controls without governance drift: nobody owns them, nobody funds them, and nobody can say whether they are enough. In interviews, governance questions test whether you can talk to executives and auditors, not just engineers.

#How it works

#The ISC2 Code of Ethics

Four canons, in priority order. When they conflict, the higher one wins:

1. Protect society, the common good, necessary public trust and confidence, and the infrastructure.
2. Act honourably, honestly, justly, responsibly and legally.
3. Provide diligent and competent service to principals.
4. Advance and protect the profession.

Example: your employer (canon 3) asks you to hide a breach that exposes customers' data. Canon 1 and 2 outrank canon 3, so you escalate and refuse.

#Due care versus due diligence

Memory aid: diligence is thinking, care is doing. Failure of due care is the basis of negligence.

#The document stack

Policy        WHAT and WHY. Mandatory, high-level, approved by senior management.
  │           "All customer data must be encrypted at rest."
  ▼
Standard      Mandatory specifics that make the policy measurable.
  │           "AES-256 via the cloud KMS; keys rotated annually."
  ▼
Baseline      Mandatory minimum configuration for a system type.
  │           "CIS Level 1 benchmark for all Linux servers."
  ▼
Procedure     Mandatory step-by-step HOW.
  │           "To enable encryption on a new database, do 1… 2… 3…"
  ▼
Guideline     RECOMMENDED advice, not mandatory.
              "Prefer client-side encryption for regulated data sets."

#Roles

#Security frameworks and control types

Frameworks such as NIST CSF, ISO 27001 and SOC 2 are compared in compliance frameworks.

📰

Real incident — the Uber breach cover-up (2016–2022). Attackers stole data on 57 million Uber riders and drivers and demanded payment. Uber's chief security officer had the payment made through the bug-bounty programme, with the attackers signing non-disclosure agreements, and the breach wasn't disclosed to regulators for a year. In 2022 he was convicted of obstruction and concealing a felony. The canons' order is not academic: concealment to protect the employer put a security leader on trial.

🎯

On the job. Governance shows up as a question you should ask whenever you're told to accept something: "who is accepting this risk, and is it written down?" A risk accepted by an engineer in a Slack thread hasn't been accepted.

#Security angle

The most common governance failure is responsibility without authority: a security team "owns" a risk it has no power to fix. Make the data owner and senior management accountable for accepting risk, in writing.

#Risk Management

#What is this?

Risk is the chance that a threat (something that can cause harm) exploits a vulnerability (a weakness) and damages an asset (something of value). Risk management is the cycle of finding risks, sizing them, choosing what to do about each, and watching for change.

#Why it matters

Security budgets are always smaller than the list of risks. Risk management is how you choose, and how you explain the choice to someone who controls the budget.

#How it works

#Quantitative risk analysis — putting numbers on it

A control is worth buying when it lowers the ALE by more than it costs per year:

Value of control = ALE before − ALE after − annual cost of control
                 = $150,000 − $30,000 − $50,000 = $70,000  → worth it

#Qualitative risk analysis

When numbers are guesses, rate likelihood and impact on a scale (low, medium, high) and plot them on a heat map. Faster and easier to agree on, less precise. Most real programmes use qualitative analysis and quantify only the biggest decisions.

#Risk responses

Inherent risk is risk before controls; residual risk is what remains after them. Residual risk must sit within the organisation's risk appetite (how much risk it is willing to take in pursuit of its goals); anything above it needs more treatment or an explicit acceptance.

#Frameworks

NIST SP 800-37 (Risk Management Framework: categorise, select, implement, assess, authorise, monitor), NIST SP 800-30 (how to conduct a risk assessment), ISO 31000 and ISO/IEC 27005. Threat modelling methods such as STRIDE feed the "threat" side; see threat modelling.

#Supply-chain risk management

Your risk includes your suppliers' risk. Assess vendors before onboarding (questionnaires, SOC 2 reports, ISO certificates), set security requirements in contracts (breach notification times, right to audit), track a software bill of materials, and reassess regularly. See dependency management for the software side.

#Security awareness

Training changes behaviour only if it is targeted and repeated: role-based training (developers, finance staff targeted by payment fraud), phishing simulations with coaching rather than punishment, and metrics such as report rate, not just click rate.

In practiceA risk register line, the artefact executives actually read:

📰

Real incident — Equifax (2017). A critical Apache Struts vulnerability (CVE-2017-5638) was publicly disclosed and patched in March 2017. Equifax's internal alert went out, but one internet-facing dispute portal wasn't patched. Attackers got in two months later and stole data on about 147 million people over 76 days, unseen partly because an expired certificate on a traffic-inspection device had silently stopped it working. Every control existed on paper; ownership and verification didn't.

🎯

On the job. When presenting a risk, give the decision-maker options with costs: "mitigate for £X by date Y, transfer partly through insurance, or accept with this residual" — and record which they chose.

#Security angle

Quantitative numbers look precise but are built on estimates; present ranges and say what drives them. And watch for "accepted" risks that were never formally accepted, which is a common audit finding.

#Asset Security — Classification, Handling and Disposal

#What is this?

Knowing what information you have, how sensitive it is, who owns it, how it must be handled through its life, and how to destroy it when it is no longer needed.

#Why it matters

You cannot protect what you have not found or labelled. Many breaches involve data that should have been deleted years earlier.

#How it works

#Classification

Classification is set by the data owner, based on the impact of disclosure, and drives handling rules: encryption, who may access it, where it may be stored, and retention.

#Data states

#Data lifecycle

Create/collect → Store → Use → Share → Archive → Destroy

At each stage ask: who can access it, is it encrypted, is it logged, and does a retention rule say it should already be gone?

#Data remanence and sanitisation

Remanence is data left behind after a "delete." NIST SP 800-88 defines three levels of sanitisation:

SSDs need special care: wear-levelling means overwriting a file does not overwrite every copy, so use the drive's sanitise command or cryptographic erase. In the cloud, crypto-shredding (deleting the encryption key) is the practical purge.

#Baselines, scoping and tailoring

Start with a standard control baseline (NIST SP 800-53, CIS Benchmarks). Scoping removes controls that don't apply (no wireless controls on a system without wireless). Tailoring adjusts the remaining controls to the organisation (stricter password length, compensating controls).

#Data loss prevention (DLP)

DLP tools inspect data at endpoints, on the network and in cloud services, find sensitive patterns (card numbers, national IDs, labelled documents) and block, quarantine or alert when they leave approved locations. DLP depends on good classification and creates false positives, so start in monitor mode.

📰

Real incident — Morgan Stanley's discarded hardware (fined 2022). Morgan Stanley hired a moving company with no data-destruction experience to decommission data-centre hardware. Devices containing unencrypted customer data were resold and turned up on an internet auction site; the firm recovered only some of them. The US SEC fined it $35 million, after an earlier $60 million penalty from the US banking regulator over the same programme. Disposal is a security control, and so is overseeing the vendor who performs it.

🎯

On the job. Ask for the certificate of destruction (with serial numbers) from disposal vendors, encrypt every drive so loss becomes a non-event, and make sure decommissioning in the cloud includes snapshots, backups and replicas, not just the instance.

#Security angle

Keep less data. Data you don't hold can't be breached, subpoenaed or ransomed.

#Security Assessment and Testing

#What is this?

The ways an organisation checks that its controls actually work: scanning, penetration testing, audits, code review and ongoing measurement.

#Why it matters

Controls decay. An untested control is an assumption. Interviewers ask you to distinguish these assessment types and to say which fits a given goal.

#How it works

• Vulnerability assessment — automated scanning plus analysis to list known weaknesses. Broad, frequent, does not exploit.
• Penetration test — authorised humans exploit weaknesses to show real impact. Narrower and deeper. Needs written authorisation and rules of engagement: scope, timing, allowed techniques, contacts, and how to handle sensitive data found.
  Black box

  no prior knowledge (simulates an outsider).

  Grey box

  partial knowledge, such as a user account.

  White box

  full knowledge, including source code and architecture.

• Red team — an objective-driven, stealthy simulation of a real adversary that tests detection and response, not just prevention. Purple teaming has attackers and defenders work together to improve detections. Breach and attack simulation tools run automated attack techniques continuously.
• Audits
  Internal (first party)

  by the organisation's own audit team.

  External (second party)

  by a customer auditing a supplier.

  Third party

  by an independent body, such as a SOC 2 auditor or ISO certification body.

• Code review and testing — static analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA), manual review, and fuzzing (feeding malformed input to find crashes). See SAST, DAST and SCA.
• Synthetic transactions — scripted transactions run continuously against production to verify availability and behaviour; real user monitoring observes actual users.
• Misuse case testing — testing what a system should not allow, written from an attacker's point of view.
• Log reviews and account reviews — periodic checks that logs are collected and reviewed and that access is still appropriate.
• Metrics
  KPIs (key performance indicators)

  how well the security programme is performing: mean time to detect, patch coverage, phishing report rate.

  KRIs (key risk indicators)

  early warnings that risk is rising: number of critical vulnerabilities older than 30 days, privileged accounts without MFA.

In practiceThe rules of engagement fit on one page, and every line prevents a real failure:

Scope:        acme.com, *.acme.com, 203.0.113.0/24, office at 1 High St (physical: lobby + floor 2 only)
Out of scope: payments processor, third-party SaaS, denial-of-service, social engineering of the CEO
Window:       2026-11-03 to 2026-11-14, 08:00–20:00 UTC; production writes require approval
Authorised by: CISO (signature) AND building owner (signature) for physical testing
Emergency stop: +44 … (24/7), testers carry a signed authorisation letter
Data handling: no exfiltration of real customer data; screenshots redacted; findings encrypted

📰

Real incident — the Iowa courthouse arrests (2019). Two penetration testers hired by the state judicial branch were arrested while testing physical security at a county courthouse at night. The state had authorised the test, but the county owned the building and hadn't agreed. The charges were eventually dropped, but the case changed how the industry writes scope: everyone who owns what you're testing must sign.

🎯

On the job. Read a pentest report for what it didn't test as much as what it found: scope exclusions, time limits and "not exploited due to rules of engagement" items are where real attackers will go.

#Security angle

A clean penetration test proves only that those testers found nothing in that scope in that week. Pair point-in-time tests with continuous scanning, detection testing and attack simulation.

#Operational Governance — Change, Configuration and Patch Management

#What is this?

The routine processes that stop well-meaning changes from creating vulnerabilities or outages.

#Why it matters

A large share of outages and many exposures come from changes: a firewall rule opened "temporarily," an unpatched server, a configuration that drifted from the baseline.

#How it works

In practiceInfrastructure as code turns a change request into a reviewable diff:

 resource "aws_security_group_rule" "admin_ssh" {
   type        = "ingress"
   from_port   = 22
   to_port     = 22
-  cidr_blocks = ["10.0.0.0/8"]
+  cidr_blocks = ["0.0.0.0/0"]        # "temporary, for the vendor"   ← reviewer should block this
 }

📰

Real incident — CrowdStrike content update (2024). A configuration update to a security agent with kernel access was pushed to customers worldwide at once and crashed about 8.5 million Windows machines. CrowdStrike's own review pointed to testing gaps and the lack of staged rollout for that type of content. Change management applies to "just configuration" and to security tools too: test, canary, stage, and keep a rollback.

🎯

On the job. Measure patching by exposure, not by count: time to patch internet-facing critical vulnerabilities with a known exploit (the CISA KEV list) is the number that matters.

#Security angle

Infrastructure as code turns change management into code review: the pull request is the change request, the pipeline is the implementation, and git history is the audit trail.

#Investigations and Evidence

#What is this?

The kinds of investigations a security team may support and the rules evidence must meet to be usable.

#Why it matters

The standard of proof and the handling rules differ by investigation type. Mishandled evidence can make a criminal case collapse or an employment decision unlawful.

#How it works

Admissible evidence must be relevant, reliable (collected properly, chain of custody intact) and lawfully obtained. Evidence types include real (physical objects), documentary, testimonial and demonstrative. Chain of custody records who handled evidence, when and why, from collection to court. See digital forensics for acquisition and writing reports.

Personnel safety always comes first: duress codes, travel security, and evacuation procedures outrank asset protection. On the exam, the answer that protects people wins.

In practiceA chain-of-custody record is a simple table that must never have gaps:

🎯

On the job. Assume any serious incident could end up in court or an employment tribunal: hash evidence on collection, work on copies, log every handler, and keep analysts' notes timestamped.

#Security angle

Decide early whether an incident might become a legal matter; if so, involve legal counsel, preserve evidence forensically and avoid tipping off the subject. See analyst OPSEC.