← CISA: audit IT, controls, and resilience
13 / 15 · 60 MIN

Trace artifacts, approvals and releases

Follow delivery from approval to the artifact actually executed, distinguishing normal and emergency paths.

The approved object must be identifiable

Release approval should be traceable to what entered production. A version name can be reused; an immutable identifier helps distinguish artifacts, provided record provenance is reliable. In the synthetic dataset, C2 approves digest-old and D2 executes digest-B. This establishes a mismatch between supplied fields. Investigation must still determine whether there was valid subsequent approval, extraction error or an unauthorized change. The auditor does not automatically turn the mismatch into proof of malicious code. Preserve records and request the chain linking build, testing, approval and deployment.

Time ordering is part of the control

For normal changes in this exercise, fictional policy requires independent approval before deployment and a matching digest. C3 was approved at minute 625, but D3 entered production at minute 620. The ticket is now approved but does not demonstrate compliance with the timing condition. Retain state history rather than only the current snapshot. Every minute in this practice uses the same UTC reference; a real system would require clock, timezone and granularity validation. A five-minute difference should not be interpreted with greater certainty than timestamp quality allows.

Independence and effective identity

D5 was operated and approved by ops-e. Exercise policy requires different people, so supplied evidence does not satisfy that condition. In a real environment, different account names do not prove independent people either: both accounts may belong to one person or an account may be shared. Map technical identities to owners and evaluate delegation. Conversely, a common role name does not establish that the same person acted without attribution data. The conclusion should identify what is demonstrated and what needs corroboration without inventing individual identity from a label.

Emergency uses a different set of criteria

D4 is classified as emergency and has no prior approval in the dataset. The query should separate it for assessment under emergency policy. Do not automatically mark it compliant or a failure of the normal path. Request the reason, authority permitting the action, impact-reduction measures, execution record and required subsequent review. Classification added after the event also needs support. A useful emergency path permits action under pressure with accountability; it is not a word that removes every requirement. The auditor applies the organization’s actual approved criteria without inventing a universal review deadline.

Traceability exercise and summary

After loading the first lesson’s data, execute this lesson’s query. Only D1 jointly satisfies the three synthetic normal-path criteria. D2 has a different digest, D3 only has later approval, D5 lacks independent approval and D6 has no matching change. D4 remains a separate assessment. Write an observation for D2 and an evidence request for D4. Avoid an overall rate mixing demonstrated failures, missing data and a path not yet assessed. Summarize the objective: connect object, time and authority while retaining exceptions requiring professional judgment.

SELECT d.id
FROM deployments d JOIN changes c ON c.id=d.change_id
WHERE c.class='standard' AND d.digest=c.approved_digest
AND EXISTS (SELECT 1 FROM approvals a
 WHERE a.change_id=d.change_id
 AND a.approved_minute<=d.deployed_minute
 AND a.approver<>d.operator)
ORDER BY d.id
IN PRACTICE

D1 passes the teaching criteria; D4 needs emergency-path analysis. A single Boolean result for both would hide different criteria.

Common pitfalls

A ticket approved today as prior approval; mutable tags as sufficient identity; separate accounts as separate people; emergency as a blanket exemption.

Related topics: CI/CD and evidence · Emergency changes

Take this idea with you

An auditable release preserves the connection between what was authorized and what ran, with criteria appropriate to each change path.

Create account

Reference: Secure Software Development Framework Version 1.1 · CISA outline effective August 1, 2024

CISA® is a registered trademark of ISACA. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by ISACA. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.