Mission
By the end of this chapter, you can trace a security or privacy obligation through requirements, controls, evidence, monitoring, exception authority, and vulnerability response.
- Measurable outcome: Map one material security/privacy obligation from risk to requirement, control, evidence, operational owner, and vulnerability-response path; score at least 3 of 4.
- Prerequisites: Chapters 7, 9, 16, 18, 25, and 27.
- Work product: A Control and Evidence Register with a vulnerability-response decision lane.
- Time: 80–100 minutes.
Before you read: Predict → Commit → Connect
Helios Support retrieves customer account history to answer billing questions. A penetration test finds that a crafted request can make the system return another customer’s ticket excerpt. The release passed its compliance checklist.
Predict: which statement is strongest: “compliant,” “secure,” “private,” or “none established”? Commit and explain. Connect to Chapter 25: a completed control is useful only when its evidence addresses the harm the program intends to prevent.
Separate four concepts that often collapse into one
Security protects confidentiality, integrity, availability, authenticity, and authorized use against threats. Privacy concerns how data about people is processed and how resulting risks affect them. Compliance demonstrates conformance to specified legal, regulatory, contractual, or policy obligations. Secure development integrates practices throughout design, implementation, build, testing, release, and response.
These overlap but are not synonyms. Compliance can supply a baseline and still miss a system-specific attack. A security control can reduce intrusion risk while creating privacy risk through excessive logging. A private design can still be unavailable. The TPM’s job is to keep these obligations connected without letting one green checklist stand in for the whole system.
NIST’s Secure Software Development Framework organizes practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. The important program lesson is lifecycle integration. Threat modeling after implementation cannot recover every architectural option. Privacy review after data has been copied into five stores becomes expensive archaeology. Vulnerability response designed after disclosure wastes the hours when coordination matters most.
Turn obligations into testable program work
Begin with assets, people, journeys, data flows, trust boundaries, threat actors, failure modes, and applicable obligations. Then write requirements precisely. “Use encryption” is not enough. Specify data state, boundary, key ownership, rotation, failure behavior, access, logging, and verification. “Follow privacy law” is not executable. Identify data purpose, allowed use, minimization, retention, deletion, access/correction obligations, transfer constraints, and evidence owner with qualified counsel.
Classify controls:
- Preventive: least privilege, isolation, input validation, secure defaults, data minimization.
- Detective: audit logs, anomaly detection, integrity checks, access review.
- Corrective/recovery: revocation, patching, rollback, credential rotation, notification and data repair.
Defense in depth matters because any one control may fail. But layers that share the same assumption may fail together. Ask whether controls are independent enough to change the outcome.
For Helios, containment might disable cross-ticket retrieval or require human-only handling for billing while the team verifies tenant isolation. Severity must consider accessible data, exploit preconditions, affected population, logging confidence, persistence, and whether an attacker exercised the path. Do not wait for a perfect root cause before containing a credible high-impact exposure.
Exceptions are decisions, not missing work
An exception record should state the unmet requirement, why it cannot be met now, affected scope, threat/harm, compensating controls, evidence, acceptor, expiry, and closure plan. “Business accepted” is insufficient. The acceptor must have actual authority and understand the residual risk. Expiry should be enforced through a control or review mechanism, not trusted to calendar memory.
Compliance evidence also needs configuration control. A report from a prior version, environment, region, or vendor may not support the current claim. Record evidence scope, date, version, assessor, and limitations.
Decision rights: Who owns what?
- Engineering/Architecture owns secure design and implementation decisions.
- Security owns security standards, threat assessment methods, and specialist acceptance routes defined by policy.
- Privacy and Legal interpret privacy obligations and notification duties; they do not replace engineering ownership of implementation.
- Compliance/Audit assesses conformance and evidence against specified obligations.
- Service/Product owners own product purpose, data use, and business risk within delegated authority.
- The TPM integrates reviews, data/control dependencies, evidence, exceptions, vendors, response paths, and decision dates. The TPM makes gaps impossible to hide but does not issue legal conclusions or security certification without authority.
I do
I translate Helios tenant isolation into a traceable requirement:
Every retrieval request must derive tenant scope from authenticated server-side identity; user text cannot select or broaden tenant scope. Automated tests attempt direct and indirect cross-tenant access. Production telemetry detects denied cross-tenant queries without logging ticket content. A separate reviewer verifies policy and test coverage before release.
I attach design evidence, negative tests, penetration-test results, log validation, open limitations, and the named operational monitor.
We do
A vendor library has a critical vulnerability score, but Helios does not call the vulnerable feature. The patched version causes a breaking change. Should the team accept an exception?
Together ask: Is the component present and reachable? Can configuration change reachability? Is there a known exploit? What data/privilege would be exposed? Can the feature be removed or isolated? How reliable is the inventory? What is the patch/verification date?
Show the model answer
Model answer
Do not decide from the severity score alone. Confirm the exact version and call path, document non-reachability evidence, disable or remove the vulnerable feature if possible, monitor configuration drift, and time-box the upgrade. An exception can be reasonable if an authorized security owner accepts the evidenced residual risk and an enforced expiry exists. If inventory or reachability is uncertain, treat that uncertainty as exposure rather than proof of safety.
Rubric (0–4)
- 0: “Critical means patch now” or “not used means ignore.”
- 1: Mentions exploitability without evidence or owner.
- 2: Considers reachability and compensating control but omits expiry/verification.
- 3: Produces a scoped, evidenced, authorized, time-bounded decision.
- 4: Also addresses configuration drift, dependency inventory confidence, disclosure, and rollback.
You do
Build this Control and Evidence Register for one flow:
| Risk/obligation | Requirement | Control type | Owner | Verification/evidence | Version/scope | Monitoring | Exception/expiry | Response action |
|---|---|---|---|---|---|---|---|---|
| Cross-tenant disclosure | Server-derived tenant boundary | Prevent/detect | Identity Eng | Negative tests + pen test | API v3/CA region | Denied-scope alert | None | Disable retrieval; rotate access |
Add a five-step vulnerability lane: intake channel, triage authority, containment options, notification decision forum, and closure verification. Run one scenario in which logs are incomplete; explain how uncertainty changes the decision.
Pause & Recall
Without looking, distinguish security, privacy, compliance, and secure development. Recall Chapter 18: when is a control assumption a risk versus an issue? Recall Chapter 27: which incident roles must join a suspected data exposure? Name one privacy control that could conflict with incident forensics and how you would resolve the decision.
Production lens
Know the software, service, model, vendor, and data inventory actually deployed. Test access revocation, credential rotation, emergency disablement, evidence preservation, and notification routing. Protect vulnerability reporters and coordinate disclosure. Reassess controls when architecture, data purpose, region, threat intelligence, or dependency versions change.
Workplace artifact: security exception record
Copyable exception record
Requirement [ID] is unmet for [scope/version] because [reason]. Credible harm is [harm] under [conditions]. Compensating controls [controls] were verified by [evidence/date]. Residual uncertainty is [unknown]. [Authorized role] accepts the risk until [enforced expiry]. Closure requires [remediation and verification]; containment trigger is [trigger/action].
Chapter compression
Security, privacy, and compliance overlap but answer different questions. Translate risk and obligation into specific requirements, layered controls, scoped evidence, monitoring, and response. Treat exceptions as explicit, authorized, expiring risk decisions. The TPM owns integration and visibility, not specialist certification.
Retrieval deck
- Q: Why can a compliant system still be insecure? A: Compliance tests specified obligations; system-specific threats or changed configurations may lie outside that evidence.
- Q: What makes evidence traceable? A: It identifies the requirement, result, version, scope, date, method, owner, and limitations.
- Q: What makes an exception legitimate? A: Scoped risk, verified compensating controls, authorized acceptance, enforced expiry, and closure plan.
- Q: Why is a vulnerability score insufficient? A: Program risk also depends on reachability, exploitability, exposure, harm, controls, and inventory confidence.
- Q: What is the TPM’s role? A: Integrate control work and decisions across seams while leaving specialist judgments with authorized owners.
Spaced review
- Now: Trace one risk to a requirement, control, evidence, monitor, and response.
- +1 day: Recreate the traceability and vulnerability-response loops from memory.
- +3 days: Inspect one exception for authority, evidence, uncertainty, and enforced expiry.
- +7 days: Build one control/evidence row for an actual deployed version.
- +14 days: Tabletop vulnerability containment and notification with the responsible functions.