Traceability Gap at a Preliminary Design Review
Program Atlas is replacing a 12-year-old warehouse management system for a defense logistics agency. The acquisition has three increments over 14 months; Increment 1, covering receiving and inventory, is at its preliminary design review. The system security engineering lead reviews the requirements traceability matrix and finds that 37 of 210 security requirements have no assigned verification method, including 6 marked 'inherited from the cloud provider.' The test lab is funded for only 9 weeks in Increment 2, and the program manager proposes deferring all 37 to operational testing to protect the schedule. The cloud provider's FedRAMP package is two authorization cycles old, and its boundary diagram does not match the proposed architecture. The customer's authorization official has not been briefed. Design review exit criteria require every security requirement to be allocated with a verification method and an acceptance criterion.
1. What should the security engineer do before the design review is allowed to close? Identify the decisions, artifacts, and sequence.
Read the worked answer
The review should not close as-is because the stated exit criterion is unmet. The engineer should first triage the 37 requirements rather than treat them as one block. Six are claimed as inherited and need provider evidence and a shared-responsibility mapping; 31 are internal and need verification methods. For each internal requirement, assign one or more methods: inspection, analysis, demonstration, or test, and write a measurable acceptance criterion. For example, 'the system shall log all privileged actions' becomes verified by test with a defined event set and retention period, not by inspection of a design document.
Next, update the requirements traceability matrix, the systems engineering management plan, and the security plan so allocation, method, responsible party, and evidence are recorded. Convene the change control board or design review board to record the 37 items as open actions with owners and dates. Brief the authorization official on the stale provider package and boundary mismatch, because inheritance claims affect the authorization boundary.
If lab time is constrained, prioritize by risk: requirements protecting high-impact data or enabling boundary enforcement should get lab test or demonstration; lower-risk items can use analysis with documented rationale. Deferral to operational testing is not automatically wrong, but it must be a deliberate, risk-assessed decision with acceptance criteria and a closure date, not an undocumented schedule workaround.
2. How should the six 'inherited' requirements be handled and traced? What evidence is needed before they can be marked as inherited?
Read the worked answer
Inheritance is a claim about control implementation by another party, not a waiver. The engineer should obtain the provider's current authorization package, control implementation statements, system boundary and data-flow diagrams, shared-responsibility matrix, assessment results, continuous-monitoring reports, and incident history. Each of the six requirements should be mapped to a specific provider control and to the customer-side responsibilities that remain, such as identity configuration, logging export, key management, and backup verification.
A two-cycle-old package and mismatched boundary are red flags. The engineer should determine whether the provider's assessed boundary actually contains the proposed architecture; if not, the inherited claim cannot be accepted for those components. Options are to obtain current evidence, commission a targeted assessment, or treat the requirement as not inherited and verify it locally. The decision and rationale belong in the security plan with an evidence reference.
Even when inheritance is valid, the customer must verify the interface: confirm that logs arrive, that encryption keys are customer-controlled where required, and that the provider's continuous monitoring covers the relevant controls. Mark inheritance type and evidence location in the traceability matrix, and schedule annual or event-driven revalidation. Without that, 'inherited' is an assertion that will not survive an assessment.
3. The program manager asks you to sign the exit checklist with a note that verification will occur later. How do you respond, and what do you document?
Read the worked answer
Signing an exit checklist that says the criterion is met when it is not would misrepresent the design state. The engineer should refuse an unqualified signature and offer a defensible alternative: a conditional closure recorded as a deviation or open action, approved by the design review board and, where authorization risk is affected, by the authorization official. The note should state exactly which requirements lack methods, the risk of deferral, the compensating review planned, the owner, and the closure date.
Documentation should include the updated traceability matrix, the board minutes, the risk assessment for deferral, and the plan for lab or alternative verification. If the lab cannot cover all 37, document the prioritization rationale. The engineer should also state the impact on the authorization package: unverified requirements may become conditions in the authorization decision or open items in the plan of action and milestones.
If pressure continues, escalate through the security engineering lead and the authorizing official's staff. The professional obligation is to make the risk visible and to avoid false assurance. A conditional, time-bound closure with named ownership is a legitimate engineering decision; a false statement that verification will simply happen later is not.