How to Test an Information Security Control: Control → Evidence → Test → Conclusion

A Practical Auditor’s Approach to Determining Whether a Control Really Works

"A control should not be considered effective simply because evidence exists. The real test is whether the evidence demonstrates that the control operated as intended and addressed the relevant risk."

An information security control can look perfectly acceptable on paper.

There may be a policy.
There may be a procedure.
There may be screenshots.
There may be reports.
There may even be management approval.

But when an auditor asks a more fundamental question—

“How did you determine that this control actually worked?”

—the assessment becomes much more interesting.

Testing a control is not simply about collecting evidence and checking whether a document exists.

A meaningful control test should establish a logical connection between:

Risk → Control → Objective → Evidence → Test → Result → Conclusion

This article presents a practical approach that auditors, GRC professionals and control owners can use to assess information security controls more consistently.

1. Start With the Control, Not the Evidence

A common audit mistake is to begin with:

“What evidence can you provide?”

A better starting point is:

“What exactly is the control intended to achieve?”

Consider this control:

“User access to critical applications shall be reviewed periodically by an authorized person.”

Before requesting evidence, an auditor should understand:

What risk is being addressed?
What applications are covered?
Which users are in scope?
What does “periodically” mean?
Who is authorized to perform the review?
What happens when inappropriate access is identified?
How are exceptions tracked?
How is remediation confirmed?

Only after understanding the control should the auditor determine what evidence is required.

2. Identify the Control Objective

Every important control should have an underlying objective.

For example:

Risk:
Unauthorized or excessive user access may result in unauthorized activity or compromise of sensitive information.

Control:
Periodic review of user access to critical applications.

Control Objective:
To ensure that user access remains appropriate, authorized and aligned with current job responsibilities.

This distinction is important.

An auditor should not merely test:

“Was an access review performed?”

The auditor should ultimately determine:

“Did the access review help ensure that inappropriate access was identified and addressed?”

That is a much stronger audit question.

3. Determine What the Control Is Supposed to Do

Before testing, break the control into its essential components.

For example:

Control Component	What to Understand
Scope	Which applications/users are covered?
Frequency	How often is the control performed?
Responsibility	Who performs it?
Authorization	Who approves/reviews it?
Process	How is it performed?
Exceptions	What happens when an issue is found?
Remediation	How is the issue corrected?
Monitoring	Is completion tracked?
Evidence	What records demonstrate performance?

This prevents the audit from becoming a simple yes/no exercise.

4. Identify the Right Evidence

Once the control is understood, determine what evidence can demonstrate that it operates.

For the access-review example, possible evidence could include:

Current user-access listing
Privileged-access listing
Access-review report
Reviewer approval
Exception report
Access-removal request
Ticket or workflow record
Evidence of remediation
Review completion record

But collecting all these documents is not necessarily the objective.

The question is:

Which evidence is sufficient and appropriate to test the control?

For example, an access-review report may show that a review occurred.

A remediation ticket may show that an inappropriate access identified during the review was subsequently removed.

Together, these may provide stronger evidence than the review report alone.

5. Design the Actual Test

This is where a control assessment becomes an audit test.

A useful testing structure is:

Control

What does the organization require?

Objective

What risk or outcome is the control intended to address?

Evidence

What records demonstrate that the control operated?

Test

What will the auditor actually verify?

Result

What did the testing demonstrate?

Conclusion

Can the auditor reasonably conclude that the control operated as intended?

6. Example: Testing a Quarterly Access Review

Suppose the control states:

“User access to critical applications shall be reviewed quarterly by the designated application owner.”

A weak audit test might be:

“Verify that quarterly access-review report is available.”

That only verifies the existence of a report.

A stronger test could be:

Step 1 — Verify scope

Obtain the application's user population and determine whether the review covers the relevant population.

Step 2 — Verify frequency

Select the required review periods and determine whether reviews were completed within the defined timeframe.

Step 3 — Verify reviewer

Check whether the person performing or approving the review was authorized.

Step 4 — Verify review activity

Examine whether the reviewer actually reviewed the relevant access information rather than merely approving a pre-prepared document.

Step 5 — Verify exceptions

Identify whether inappropriate, excessive or obsolete access was identified.

Step 6 — Verify remediation

For identified exceptions, check whether corrective action was completed.

Step 7 — Verify closure

Determine whether the exceptions were appropriately closed and whether supporting evidence is available.

This produces a much stronger assessment than simply checking whether a report exists.

7. Evidence Does Not Tell You What to Test

One important audit principle is:

Evidence should support the test; it should not define the test.

Suppose an organization provides a beautifully formatted access-review report.

The report may contain:

User ID
Department
Role
Reviewer
Date
Approval

It may look complete.

But the auditor should still ask:

Is the user population complete?
Is the source reliable?
Are terminated users included?
Are privileged accounts included?
Are service accounts included?
Were exceptions identified?
Were exceptions corrected?

A well-designed document can still represent an incomplete control.

8. Test the Population Before Selecting Samples

Sampling is frequently used during information security audits.

However, before selecting a sample, the auditor should understand the population.

For example:

The organization states that 2,500 users are covered by quarterly access reviews.

Before selecting 25 users for testing, consider:

How was the population generated?
Does it include all relevant systems?
Does it include privileged accounts?
Does it include service accounts?
Does it include temporary users?
Does it exclude inactive or terminated accounts?
Is the population complete for the period being tested?

If the population itself is incomplete, a technically correct sample may still produce a misleading conclusion.

Important principle

A good sample from a poor population is still a poor test.

9. Test More Than One Dimension

A useful control test often examines several dimensions.

For a periodic access-review control:

Test Dimension	Example Test Question
Completeness	Is the full relevant population included?
Accuracy	Does the report accurately represent current access?
Frequency	Was the review performed as required?
Authorization	Was it performed by an appropriate person?
Effectiveness	Were inappropriate accesses identified?
Remediation	Were exceptions corrected?
Timeliness	Were corrections completed within defined timelines?
Evidence	Can the results be independently verified?

This approach makes the test more meaningful.

10. A Practical Example: Vulnerability Remediation

Consider another common control:

“Identified critical vulnerabilities shall be remediated within the defined timeframe.”

The organization provides a vulnerability assessment report.

Is that sufficient?

Not necessarily.

The report demonstrates that vulnerabilities were identified.

It does not automatically demonstrate that they were remediated.

A practical test could be:

Vulnerability Report → Identify Critical Findings → Select Sample → Verify Remediation → Verify Retest → Check Closure

For a selected vulnerability, the auditor may examine:

Original vulnerability identification
Severity/risk classification
Asset affected
Remediation ticket
Assigned owner
Target date
Actual remediation date
Patch/change evidence
Retest or validation evidence
Final closure

The critical distinction is:

Detection is not remediation.

11. Another Example: Backup Control

Consider the control:

“Critical systems shall be backed up according to the defined backup schedule.”

An organization provides a backup report showing:

Status: Successful

An auditor should consider whether this demonstrates the intended control objective.

Possible testing areas include:

Are all critical systems covered?
Is the backup frequency appropriate?
Did backups operate throughout the required period?
Are failed backups identified?
Are failures investigated?
Are backups protected from unauthorized access?
Is backup retention appropriate?
Has restoration been tested?
Is there evidence that restored data is usable?

This highlights an important distinction:

A successful backup does not necessarily prove that data can be successfully restored.

Where restoration capability is part of the control objective, restore testing becomes relevant evidence.

12. Test Exceptions — They Often Tell the Real Story

Exceptions are not necessarily evidence that a control is useless.

In fact, a mature control may identify exceptions precisely because the control is functioning.

The important question is:

What happened after the exception was identified?

Consider:

Control performed → Exception identified → Owner assigned → Corrective action → Review → Closure

An auditor should determine whether this chain exists.

For example:

Five inappropriate user accounts were identified during an access review.

If the organization subsequently:

Assigned responsibility
Removed inappropriate access
Recorded the action
Obtained appropriate approval
Retained evidence

then the control may have demonstrated its ability to detect and address the issue.

But if the five exceptions remain unresolved without justification or escalation, the effectiveness assessment may be different.

Therefore:

Do not stop testing when you find an exception. Test what happened next.

3. Distinguish Control Failure From Evidence Failure

This is an important distinction in audit reporting.

Suppose the organization says:

“The control was performed, but the supporting evidence could not be produced.”

There are at least two separate questions:

Scenario A — Control was not performed

There is evidence indicating that the required activity did not occur.

This may indicate an operating failure.

Scenario B — Control was performed but evidence is unavailable

The activity may have occurred, but the organization cannot demonstrate it adequately.

This may indicate an evidence/documentation weakness, depending on the circumstances and applicable requirements.

These situations should not automatically be treated as identical.

An auditor should establish the facts before concluding.

14. Use the “Show Me” Test

A simple practical technique for auditors is to keep asking:

“Show me.”

Control requirement:
Show me the requirement.

Implementation:
Show me how it is implemented.

Operation:
Show me that it operated.

Exception:
Show me what happened when something went wrong.

Remediation:
Show me how the issue was corrected.

Closure:
Show me how you know it was resolved.

This technique helps move the assessment from documentation toward actual control operation.

15. The Control Testing Worksheet

A simple worksheet can make control testing more consistent.

Field	Example
Control ID	AC-01
Control	Quarterly user access review
Risk	Unauthorized or excessive access
Objective	Ensure access remains appropriate
Owner	Application Owner
Frequency	Quarterly
Population	All application users
Evidence	Access review report
Sample	Selected users/review periods
Test	Verify completeness, review, exceptions and remediation
Exceptions	Inappropriate access identified
Remediation	Access removed
Result	Control operated with exceptions addressed
Conclusion	Evidence supports operating effectiveness

The exact fields can be adapted to the organization's audit methodology.

16. Common Control Testing Mistakes

Mistake 1: Testing the document instead of the control

A document exists, so the control is marked compliant.

Better approach: Test what the document proves and what it does not prove.

Mistake 2: Accepting one sample as proof of continuous operation

One successful transaction or report does not necessarily demonstrate recurring performance.

Better approach: Align testing with the control frequency and audit period.

Mistake 3: Ignoring the population

A sample may look correct while the underlying population is incomplete.

Better approach: Establish population completeness before sampling.

Mistake 4: Ignoring exceptions

The auditor verifies that a control was performed but does not examine exceptions.

Better approach: Follow exceptions through remediation and closure.

Mistake 5: Confusing activity with outcome

A review occurred, so the control is considered effective.

Better approach: Determine whether the review achieved its intended objective.

Mistake 6: Treating missing evidence as automatic proof of control failure

Evidence may be incomplete for different reasons.

Better approach: Establish whether the control failed, evidence was not retained, or evidence was not available to the auditor.

17. A Five-Step Practical Method

For routine control testing, the following five-step approach can be used:

Step 1 — Understand

Understand the risk, control and objective.

Step 2 — Obtain

Obtain appropriate and relevant evidence.

Step 3 — Test

Perform inspection, inquiry, observation, reperformance, sampling or other appropriate procedures.

Step 4 — Evaluate

Assess exceptions, deviations, evidence quality and control outcomes.

Step 5 — Conclude

Determine whether the evidence supports the intended audit conclusion.

In simple form:

Understand → Obtain → Test → Evaluate → Conclude

18. From Checkbox Testing to Risk-Based Testing

There is a major difference between these two approaches.

Checkbox approach

Policy available? Yes

Report available? Yes

Approval available? Yes

Control effective? Yes

Risk-based approach

What risk does the control address?

Is the control designed appropriately?

Does the evidence cover the required population and period?

Did the control operate as required?

What exceptions occurred?

Were they addressed?

Does the evidence support the intended control objective?

The second approach provides a much stronger basis for an audit conclusion.

19. A Simple Formula for Better Control Testing

A practical way to remember the methodology is:

CONTROL + OBJECTIVE + EVIDENCE + TEST + EXCEPTION ANALYSIS = MEANINGFUL CONCLUSION

If any important component is missing, the auditor should consider whether additional work is necessary.

The objective is not to make the audit unnecessarily complicated.

The objective is to make the conclusion defensible, evidence-based and connected to the actual risk.

20. Final Auditor Perspective

A good control test should allow an auditor to explain:

What was tested?

Why was it tested?

What evidence was examined?

How was it tested?

What exceptions were identified?

What happened to those exceptions?

What conclusion does the evidence support?

If these questions can be answered clearly, the audit conclusion becomes much stronger.

The auditor's role is not simply to determine whether a document exists.

It is to determine whether the available evidence provides a reasonable basis to conclude that the control is appropriately designed, implemented and operating as intended, within the scope and period being assessed.

Key Takeaways

Start with the risk and control objective, not with the evidence.
Understand exactly what the control is supposed to achieve.
Establish the relevant population before selecting samples.
Select evidence that can actually support the control test.
Test completeness, accuracy, frequency, authorization and effectiveness where relevant.
Follow exceptions through remediation and closure.
Distinguish between a control failure and an evidence/documentation weakness.
Do not treat one successful sample as automatic proof of continuous operation.
Test the outcome, not just the activity.
A strong audit conclusion should be traceable back to the control, evidence and testing performed.

The key question is:

“What did I actually test, what did the evidence demonstrate, and does that support my conclusion?”

About the Author

Vipin Kumar Tiwari, CISA, is an Information Security and Cyber GRC professional with 16+ years of IT experience, with a professional focus on Information Security Audit, ISO/IEC 27001, ISO/IEC 27701, privacy, regulatory compliance and IT governance.

Professional Focus

Professional Discussion

I share practical insights and approaches related to Information Security, Cyber GRC, IT Audit, privacy and regulatory compliance.

For professional discussions and knowledge sharing in these areas, feel free to connect.

Primary Keywords: Information Security Control Testing, IT Audit, Control Testing, Audit Evidence, Information Security Audit, Cyber GRC, ISO 27001 Audit