Governing Security Policy
Given a system, change, or incident to evaluate, produce four artifacts in order:
- Security Assessment — narrative of what was reviewed, scope, and findings
- Risk Score — quantified risk (e.g., 1-10 or Low/Medium/High/Critical) per finding + overall
- Control Matrix — table mapping threats to existing/required controls
- Mitigation Plan — prioritized, actionable remediation steps with owners and timelines
Example invocation: "A new vendor API will handle customer PII. Assess the security risk." → Run the full workflow below and output all four sections.
Progress:
- Step 1: Define scope (what system/asset/process is being governed)
- Step 2: Identify trust boundaries (who/what is trusted, at what level)
- Step 3: Enumerate threats against those boundaries (STRIDE or similar)
- Step 4: Score risk (likelihood × impact) per threat
- Step 5: Map each threat to existing controls; flag gaps
- Step 6: Produce prioritized mitigation plan for gaps
Step 1 — Scope Identify the asset (system, data flow, integration, access path). State explicitly what is IN and OUT of scope.
Step 2 — Trust Boundaries List all actors/components and their trust level: Untrusted, Semi-trusted (external partner), Trusted-internal, Privileged/Admin. Flag any boundary crossing without validation (e.g., untrusted input reaching a trusted process).
Step 3 — Threat Enumeration Use STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. For each applicable threat, describe the attack vector concretely (not generic).
Step 4 — Risk Scoring
Score each threat: Risk = Likelihood (1-5) × Impact (1-5), then bucket:
- 1-6: Low
- 7-14: Medium
- 15-20: High
- 21-25: Critical
Overall risk score = highest individual score, noted alongside average.
Step 5 — Control Matrix
Table columns: Threat | Likelihood | Impact | Risk Score | Existing Control | Status (Adequate/Gap/Missing) | Required Control
Step 6 — Mitigation Plan
Prioritize by risk score descending. Each item: Action | Owner | Priority (P0-P3) | Target Timeline | Dependency
Example 1: Input: "New vendor API integration will handle customer PII, authenticated via a shared API key stored in a config file."
Output:
Scope: Vendor API integration for PII exchange. Reviewed authentication method, data-in-transit handling, and credential storage. Shared API key stored in plaintext config file is a critical exposure point; no key rotation or scoping observed.
- Credential exposure (plaintext key in config): Likelihood 4, Impact 5 → 20 (High)
- No key rotation: Likelihood 3, Impact 4 → 12 (Medium)
- PII in transit without confirmed TLS enforcement: Likelihood 2, Impact 5 → 10 (Medium) Overall: High (20)
| Threat | Likelihood | Impact | Risk Score | Existing Control | Status | Required Control |
|---|---|---|---|---|---|---|
| Credential leak via config file | 4 | 5 | 20 | None | Missing | Secrets manager (Vault/KMS) |
| Stale/compromised key never rotated | 3 | 4 | 12 | None | Missing | 90-day auto-rotation policy |
| PII intercepted in transit | 2 | 5 | 10 | TLS assumed | Gap | Enforce TLS 1.2+, cert pinning |
- Move API key to secrets manager — Security Eng — P0 — 3 days — none
- Enforce TLS 1.2+ with cert validation — Platform Eng — P0 — 3 days — none
- Implement 90-day key rotation — Security Eng — P1 — 2 weeks — secrets manager
- Add audit logging on key usage — Security Eng — P2 — 3 weeks — secrets manager
- Always tie risk scores to concrete, described attack vectors — never score abstractly.
- Treat any trust-boundary crossing (external → internal, untrusted → privileged) as high scrutiny by default.
- Prefer least-privilege and default-deny framing in required controls.
- Distinguish "Gap" (partial/unverified control) from "Missing" (no control at all) — mitigation urgency differs.
- Mitigation actions must be specific and assignable — no vague items like "improve security."
- Re-score risk after proposed mitigations are applied to show residual risk if asked.
- Don't skip trust boundary mapping — most real risk lives at boundary crossings, not inside trusted zones.
- Don't assign risk scores without stating both likelihood and impact separately.
- Don't produce a mitigation plan without prioritization — unordered lists get ignored.
- Don't conflate compliance checklists with actual risk assessment; policy adherence ≠ absence of risk.
- Don't omit the "Status" column in the control matrix — a control's mere existence isn't sufficient, its adequacy must be stated.