A completed checklist, an approved access review, and a screenshot of a security dashboard can all look convincing in an audit file. Each shows that something happened. Whether the control actually addressed the risk requires a closer look.
As internal auditors, we need evidence that supports a clear conclusion about control effectiveness. Management’s explanation helps us understand the process. Our testing needs to establish whether the control was appropriately designed and operated as intended.
Good cybersecurity audit evidence connects the risk, the control activity, and the result. Gathering it starts with knowing what we need to demonstrate.
Start With the Risk and Expected Result
Before requesting evidence, define what the control should accomplish.
Consider employee offboarding. The risk is that a former employee retains access to organizational systems and information. The control might require disabling access within a specified period after employment ends.
An approved termination ticket provides part of the evidence. To determine whether the control worked, we also need the employee’s termination date, the required removal deadline, the systems involved, and records showing when access was disabled.
A ticket marked “complete” may reflect an administrative update without confirming that access ended everywhere required.
Evidence requests become more useful when they follow a specific question: What would demonstrate that this control addressed the identified risk?
Distinguish Design From Operation
Control design and operating effectiveness require related but different evidence.
Design evidence helps us evaluate whether the control could reasonably address the risk. Relevant information may include procedures, responsibilities, system configurations, review criteria, escalation requirements, and defined completion deadlines.
Operating evidence shows how the control performed during the period under review. Examples include transaction records, system logs, completed reviews, investigation notes, and documented corrective actions.
For a privileged access review, the procedure might require managers to evaluate administrative permissions quarterly. Design testing should consider whether reviewers receive enough information to make informed decisions and whether inappropriate access must be removed promptly.
Operating testing should examine whether those reviews occurred, whether reviewers evaluated the permissions, and whether required changes were completed.
A well-written procedure cannot establish consistent operation. A completed review cannot compensate for a design that leaves significant access risks unaddressed.
Look Beyond Approval
Approvals are common audit evidence because they are easy to identify and retain. Their value depends on what the approver actually evaluated.
Suppose a manager approved a list of users with access to a financial application. The approval establishes that the manager signed off. Additional evidence is needed to understand whether the review was meaningful.
Useful questions include:
Did the listing include all relevant users and permissions?
Could the reviewer understand what the permissions allowed?
Were privileged, inactive, and unusual accounts identifiable?
Were decisions based on current job responsibilities?
Were requested changes implemented and verified?
Review comments, supporting explanations, and access removal records help connect approval to the control’s purpose. An approval with no visible changes is not automatically ineffective, but it deserves enough examination to understand the work performed.
Validate the Information Used
A control can operate exactly as described and still fail because its underlying information is incomplete or inaccurate.
For example, a vulnerability management team may consistently remediate critical findings on its monthly report. The process provides limited protection if the scanning tool excludes important servers.
Auditors should evaluate the information supporting both the control and their own testing. Depending on the circumstances, that may involve reviewing report parameters, reconciling records to another source, inspecting extraction logic, or tracing selected records to originating systems.
For vulnerability management, comparing scan coverage with the asset inventory can help identify missing systems. Reviewing authenticated scan results can help determine whether scans obtained the access needed to perform the intended checks.
Confidence in the conclusion depends partly on confidence in the population being examined.
Combine Evidence Sources
Different evidence sources answer different questions.
Interviews explain how people understand and perform the control. Procedures describe expectations. Configurations show how technology is set up. Logs and transaction records show recorded activity. Observation and reperformance can help establish whether the process behaves as expected.
NIST’s security and privacy control assessment approach recognizes three assessment methods: examine, interview, and test. Selecting an appropriate combination helps assessors gather evidence suited to the assessment objective.
For backup controls, a successful job report supports the conclusion that a backup process completed. A restoration test provides evidence about whether selected data can be recovered. Comparing restoration results with recovery requirements helps determine whether the capability supports business needs.
No single artifact necessarily answers every relevant question.
Match the Evidence to the Period
A screenshot captured today shows a condition at a particular moment. Its ability to support a conclusion about the previous six months depends on additional evidence.
For automated controls, current configuration evidence may need support from change records, configuration history, and evidence about relevant dependencies. For recurring manual controls, testing should cover an appropriate selection of occurrences across the audit period.
Sample selection should reflect the control’s frequency, risk, population, and intended assurance. Unusual transactions, changes in personnel, and periods of operational disruption may warrant particular attention.
An annual recovery exercise completed last week does not establish that monthly backup reviews occurred throughout the year. The evidence must match the activity and timeframe being evaluated.
Follow Exceptions Through Resolution
Exceptions often provide the clearest view of how a control functions.
A monitoring process may generate alerts consistently while leaving serious issues unresolved. A patching process may identify overdue vulnerabilities without escalating them.
Follow selected exceptions from identification through investigation, action, and closure. Evaluate whether decisions were timely, responsibilities were clear, and closure was supported by evidence.
Where management accepts a risk, examine the approval, rationale, duration, and any conditions attached to that decision. Risk acceptance should be assessed against the organization’s requirements.
The presence of exceptions does not automatically mean a control failed. How the organization handles them can demonstrate whether the control works.
Make the Conclusion Traceable
Another auditor should be able to follow the work from risk to conclusion. Document the objective, population, selections, procedures, results, and limitations. Preserve enough context to explain where evidence came from and what it demonstrates.
Our conclusion should stay within those boundaries. Testing selected access removals supports a conclusion about that control within the scope examined; it does not establish that the entire cybersecurity program is effective.
Strong cybersecurity audit evidence gives leaders a defensible basis for understanding where controls work, where protection is incomplete, and what needs attention.
