Security View design intermediate

Security Control Matrix

Each required control mapped to the specific mechanism that implements it, the evidence it produces and the person accountable for it.

The bridge between a framework's control list and the actual system. Its value is in the last three columns: without a named mechanism, an evidence source and an owner, a control is an intention.

The shape

Ref Control requirement Implemented by Evidence Owner Status
AC-2 Unique identity per user; no shared accounts SSO with directory; shared accounts blocked by policy-as-code Quarterly identity report; policy CI check Identity Effective
AC-6 Least privilege; privileged access time-bound JIT elevation, 60 min, approved Elevation log export Identity Effective
SC-8 Data encrypted in transit TLS 1.3 at edge, mTLS service-to-service via mesh Mesh config scan; TLS scanner Platform Effective
SC-28 Data encrypted at rest Envelope encryption, CMK per environment Key inventory; storage scan Platform Effective
AU-2 Security-relevant events logged Structured audit stream, append-only, 400-day retention Log completeness probe SRE Effective
AU-9 Logs protected from modification Write-once storage; no operational role can delete IAM policy export Security Effective
CM-3 Changes authorised and traceable Pipeline gate; commit → build → deploy chain Deployment records Delivery Effective
CP-9 Backups tested Automated restore test, monthly Restore test report Platform Partial — quarterly, not monthly
RA-5 Vulnerabilities identified and remediated Image and dependency scanning; SLA by severity Scanner export; ageing report Security Partial — SLA missed on medium
IR-4 Incident response exercised Game day, half-yearly Exercise report SRE Effective

When you produce it

When entering a certification process, responding to a customer security questionnaire, or remediating an audit finding. Also during vendor selection, as the thing you ask a vendor to complete rather than accepting their brochure.

Who reads it

Auditors and assessors, who work through it row by row. Security, who maintain it. Engineering leads named in the owner column. Sales, when a customer's security team asks.

What good looks like

  • The evidence column names something a machine produces, so the assessment is a query rather than a screenshot-gathering exercise.
  • Partial and failing controls are stated as such, with what is missing. Auditors find the gaps anyway; finding them first is the difference between a conversation and a finding.
  • One mechanism can satisfy several controls, and the matrix should show that reuse rather than duplicating effort.
  • Owners are individuals, and they know.
  • Status has a date. Controls decay.

Common mistakes

  • Everything green. Nobody believes it, and it destroys the credibility of the rows that are genuinely fine.
  • "Documented in the security policy" as the mechanism. A policy is not a control; the thing that enforces it is.
  • Evidence that is a person taking a screenshot, which does not scale and cannot be continuous.
  • Writing it once for the audit, then letting it go stale for a year.