Helpful first: Threat, vulnerability, and risk: the core equation · Logs, alerts, and evidence: why an alert title is a hypothesis, not proof · Outcomes before controls: using NIST CSF, CIS, ISO 27001, and ATT&CK together
Key points
- Decompose vague technical findings into cause, threat event, affected asset, and business impact
- Assign an accountable risk owner who holds budget and operational authority over the affected asset
- Separate inherent risk from residual risk when documenting entries in the organizational risk register
Why one-word risks fail in engineering and boardrooms
Walk into a poorly run governance meeting and you will see a spreadsheet listing risks like "Ransomware", "Cloud Misconfiguration", or "Insider Threat". None of those phrases is a risk statement. "Ransomware" is a threat mechanism; "Cloud Misconfiguration" is a vulnerability category; neither tells an engineer what system to fix or tells an executive what mission outcome is on the line.
At Meridian Space & Robotics (chronos.), VP of Legal & Compliance Sloane Sterling and Principal Security Architect Vera Vance enforce a strict four-part risk sentence: If [threat source / event] exploits [specific control gap / vulnerability] on [named asset], then [quantified or bounded mission/business impact] occurs.
| Weak Label | What Is Missing? | Structured Meridian Risk Sentence | Accountable Risk Owner |
|---|---|---|---|
| "S3 bucket risk" | No threat actor, no specific bucket, no CIA failure mode | If an external scanner queries unauthenticated read ACLs on the chronos- S3 bucket, confidential thruster CAD files are disclosed, violating export-control regulations. | VP of Propulsion Engineering (asset owner) |
| "Third-party vendor outage" | No named supplier, no RTO/SLA boundary, no mission effect | If our single-source weather telemetry provider suffers an API outage exceeding 45 minutes during a launch window, launch countdown must be scrubbed at a cost of $380K per delay. | Director of Launch Operations |
| "Stale contractor accounts" | No access path, no target system, no impact | If a departed contractor retains active VPN and OIDC tokens after contract end, unauthorized commands could alter staging ground-station configs (chronos-). | VP of Infrastructure & Identity |
Who owns the risk? (Hint: not the security team)
One of the most important principles in CISSP Domain 1 and NIST RMF is risk ownership. Security engineers and GRC analysts advise, measure, and build controls, but they do not own business risk. The Risk Owner must be a senior business or mission leader who holds budget authority, operational accountability, and decision rights over the system generating the risk.
Why? Because choosing how to respond to a risk - whether to spend $150,000 engineering hours to mitigate it, buy cyber insurance to transfer financial loss, shut down the feature to avoid it, or formally accept the residual risk - is a business trade-off against mission schedule and capital.
Scoring likelihood, impact, and review cadence
Once the risk sentence and owner are recorded in Meridian’s risk register, the team scores inherent risk (before controls) and residual risk (after current controls) across likelihood and impact scales, or calculates annualized loss figures (SLE × ARO = ALE). Every accepted or mitigated entry receives a mandatory review date and trigger condition so risk registers stay living operational artifacts rather than static compliance shelfware.
CHECK YOUR JUDGMENT
A junior analyst at Meridian Space & Robotics (chronos.orbital ) submits a draft risk register entry that reads: "Risk #42: Phishing. Owner: Nyx (Threat Hunter)." Why does VP of Legal & Compliance Sloane Sterling send this entry back for revision?
NEXT FIELD LESSON