Hands-On Audit Labs

Score each entity numerically: rate impact and likelihood (say 1–5), then adjust upward for weak control maturity, high regulatory exposure, and long time since last audit. A defensible ranking: (1) Customer web app — high inherent risk, weak controls, GDPR exposure; (2) Payment processing — high risk, PCI exposure, 26 months unaudited; (3) Data-center facilities or Procurement — the highest-scoring medium.

The point: the plan covers the highest residual risk — not the most recently audited, not what management prefers, and not the most technically interesting. If a material new risk emerged mid-year (e.g., a breach), you’d update the plan to include it. The scoring criteria and weights should be documented and approved by the audit committee so the ranking is defensible, not subjective.

Sample deviation rate = 4 / 40 = 10%, which exceeds the 5% tolerable rate. Conclude the control is ineffective and report the finding with the supporting evidence.

Traps to avoid: don’t increase the sample and re-test until the rate falls within tolerance (result-shopping); don’t lower the tolerable rate to match the result (rationalizing the failure). Additional inquiry of management may add context on why the deviations occurred, but it does not change the fact that the tested control failed against the pre-set criterion.

Governance (EDM): a (sets appetite), c (evaluates value), e (directs strategy). Management: b (builds/configures), d (runs and monitors execution), f (runs operations).

The rule: governance evaluates, directs, and monitors — the governing body sets direction, risk appetite, and oversight. Management plans, builds, runs, and monitors the execution of that direction. If the actor is the board / steering committee setting direction or judging value, it’s governance; if the actor is executing or operating, it’s management. (Note that both governance and management “monitor” — the difference is oversight vs. operational monitoring.)

1. Exceptions in logical access — assess their nature and whether they affect the controls you rely on; a Type II reports operating effectiveness over the period, so exceptions matter.
2. CUECs are your responsibility, not the vendor’s. Verify your organization actually performs the quarterly privileged-access review — an untested CUEC is an unverified control.
3. Four-month gap between period-end and your reliance date — obtain a bridge (gap) letter or perform additional procedures over the intervening period.
4. Carved-out subservice provider — those controls are not covered by this report; obtain separate assurance (e.g., the subservice provider’s own SOC report).

The population is the flow of releases over the period, not one milestone. Take a risk-based sample of user stories / releases across several sprints. For each sampled release, test that it carried the required controls: security acceptance criteria met; code review and automated pipeline gates (SAST / DAST / SCA) passed; deployment approval enforced before code reached production; and documentation maintained.

Sprint retrospectives improve the team but are not a substitute for the requirements baseline and control documentation an audit relies on. Agile is not inherently insecure — the auditor’s concern is whether the audit checkpoints and controls are adapted to the sprint cycle rather than assumed absent.

73% compliance against a critical-patch SLA is a control failure, not a pass — the testing process is creating unacceptable risk by delaying critical patches beyond policy. Investigate the root cause and either improve / parallelize testing or formally revise the SLA with documented risk acceptance by the business.

Don’t simply rush the four late patches into production (that treats the symptom), and don’t accept “beats the industry average” as a pass. Classic patch findings: no SLA for critical patches, patching production without testing, no tracking of non-compliant systems, and end-of-life systems without compensating controls.

RTO gap: tested recovery of 10–12 hours vs. the 4-hour requirement — a critical finding. RPO gap: nightly backups permit up to ~24 hours of data loss vs. the 1-hour requirement — the recovery-point objective cannot be met with this backup cadence.

The principle: the BIA drives the objectives; the DRP must be built and funded to meet them — you don’t revise the BIA upward to fit the DRP’s current capability. Recommend a higher-tier strategy for this system (e.g., a hot site with synchronous / near-synchronous replication), or a documented business decision to accept a lower objective. A DRP whose tested capability doesn’t meet the BIA is a finding, not reassurance.

1. Wrong reviewer. Recertification should be performed by the business managers who know whether each user’s access is appropriate for their current role — the IT security team can’t judge business need. The system reports are fine; the reviewer is the problem.
2. Terminated accounts still active — a provisioning / deprovisioning gap; deprovisioning should be triggered by HR on termination.
3. Access creep (admin rights retained after a role change) — least privilege isn’t enforced on role transitions.

Recommend business-owner recertification, HR-triggered deprovisioning, and periodic least-privilege / role-change reviews.

1. Keys stored with the data undermine the entire encryption control — the most common encryption finding is weak key management, not a weak algorithm (AES-256 and TLS 1.2 are acceptable). Keys must be stored separately, rotated, and revocable (ideally in an HSM).
2. Single badge door = no defense in depth — each security zone should be protected by multiple independent layers; one control is one layer.
3. IoT on the production segment is a network-segmentation gap; isolate the IoT devices from production systems.

The through-line: no single layer is trusted alone, and a strong control (encryption) is only as good as its weakest supporting practice (key management).

Correct lifecycle: Preparation → Detection & Analysis → Containment → Eradication → Recovery → Post-Incident Activity.

Errors: eradicating before containing risks the malware spreading during cleanup; powering off the server destroyed volatile evidence and broke chain of custody before the cause was understood; restoring from backup before eradication can reintroduce the threat. Contain first, then eradicate.

Order of volatility — capture the most perishable evidence first: CPU registers & cache → RAM / memory and active network connections → disk → archival media. Powering off the server threw away the memory and network state that should have been imaged first.