Compliance Risk Assessment: Definition, Matrix, and Workflow

A compliance risk assessment is the structured process of identifying the ways your company could fail its legal, regulatory, and contractual obligations, scoring each risk by likelihood and impact, and deciding what to do about the ones that matter. It is a required artifact in SOC 2, ISO 27001, and GDPR programs, and the input that decides where your compliance effort goes first.

Why every framework asks for one

Frameworks converge on risk assessment because it is the reasoning layer that justifies everything else. SOC 2's CC3 series requires risk identification and analysis, including fraud risk. ISO 27001 clauses 6.1.2 and 8.2 require a documented, repeatable methodology whose results are "consistent, valid and comparable," and the risk treatment plan drives your Statement of Applicability. GDPR Article 32 requires security "appropriate to the risk," which presumes you assessed one. An auditor who finds no risk assessment concludes your controls were chosen by copying a template, and reads everything else accordingly.

The likelihood x impact matrix

The standard scoring model multiplies likelihood by impact on simple scales. A 3x3 matrix is enough for most 5-200 person companies; 5x5 adds resolution if you have many risks to rank. Score = likelihood x impact:

Define the anchors in writing so scoring is repeatable: for example, high impact = regulatory fine, contract loss, or breach notification; medium = customer escalation or audit exception; low = internal rework. Likelihood anchors work well as frequency: high = plausible this year, medium = plausible within three years, low = rarer. Written anchors are what make this year's scores comparable to next year's, which is exactly what ISO 27001 requires.

What to actually put on the list

Compliance risks come in recognizable families. Seed the register from these and you will cover most of what an auditor expects:

• Access risks: a departed employee retains production access; shared credentials; no MFA on an admin surface
• Obligation risks: a DPA never signed with a vendor; a DSAR deadline missed; a certificate or attestation lapsing unnoticed
• Operational risks: backups that have never been restore-tested; an unreviewed emergency deploy path; logging gaps that would blind a breach investigation
• Vendor risks: a critical processor with no security review; concentration on one provider with no continuity plan. Scoring and tracking these belongs in a dedicated vendor risk management register so nothing critical goes unreviewed.
• People risks: onboarding without security training; phishing exposure; no offboarding checklist

The register workflow

The assessment produces a register; the register is only alive if each row moves through a defined workflow:

1. Identify: capture the risk with a plain-language description of the failure and the obligation it threatens.
2. Score: likelihood x impact against your written anchors.
3. Decide treatment: mitigate (add or strengthen a control), transfer (insurance, contract terms), avoid (stop the activity), or accept. Acceptance requires a named approver; "nobody got around to it" is not acceptance.
4. Assign an owner and due date: every treated risk becomes a task with a deadline; every mitigation maps to a control in your control set, which is how the register connects to your control mapping rather than floating beside it.
5. Track to residual risk: after treatment, re-score. The residual score is what you report and what the auditor reads.

Cadence: how often to reassess

• Full reassessment: annually. Every framework treats a risk assessment older than 12 months as stale.
• Triggered reviews: on material change. New product line, new data category, major vendor swap, security incident, or entering a regulated market each warrant re-scoring the affected rows within the quarter.
• Register review: quarterly. A standing 30-minute review of open treatments and due dates keeps the register from silently expiring, and produces exactly the dated, attributed records auditors sample; see audit evidence examples for what those records should look like.

Common failure modes

• The heroic first draft. Forty risks scored in one afternoon, never touched again. A smaller register that is actually reviewed quarterly audits far better.
• Scores without anchors. If "medium" means something different to each scorer, trend lines are noise and auditors notice the inconsistency.
• Treatments without owners. A mitigation with no name and no date is a wish. Auditors sample precisely these rows.
• A register disconnected from controls. If mitigations do not map to your actual control set, the register describes a parallel imaginary program.

The usual boundary applies: a risk assessment is required input for SOC 2, ISO 27001, and GDPR work, but it does not by itself certify anything or guarantee an audit outcome. Auditors judge whether the process is real; a maintained register is how it looks real, because it is.

Keeping the register alive without a spreadsheet

Spreadsheets hold risk registers; they just do not chase owners, expire scores, or connect mitigations to controls. Complies runs the register as a living workflow: risks scored on your matrix, treatments assigned with owners and due dates on the compliance calendar, mitigations mapped to controls that count across SOC 2, ISO 27001, GDPR, HIPAA, and PCI DSS, and the whole thing feeding your live readiness score. It is self-serve, with published prices from $79 per month and no sales call. See how risk register software keeps the quarterly cadence honest, and get started with the five risk families above.