ISO 27001 Internal Audit: How to Assess Control Effectiveness Beyond Documentation

Disclosure: This post contains affiliate links. If you click through and make a purchase, I may receive a small commission at no extra cost to you. As an Amazon Associate, I earn from qualifying purchases.

A Practical Auditor’s Guide to Moving from “Compliant on Paper” to “Working in Practice”

"An effective internal audit does not simply verify that controls are documented. It assesses whether those controls are implemented, operating as intended, supported by appropriate evidence, and addressing the relevant risks."

An organization may have a well-written Information Security Management System (ISMS), approved policies, documented procedures, risk assessments, a Statement of Applicability (SoA), and a complete set of audit evidence.

On paper, everything may appear to be in place.

But an internal auditor should ask a more important question:

Does the ISMS actually work in practice, or does it simply look complete on paper?

This is where an effective ISO/IEC 27001 internal audit becomes different from a document verification exercise.

An internal audit should provide useful assurance about whether the ISMS and its controls are implemented and operating as intended within the defined scope.

The auditor therefore needs to look beyond:

“Is the document available?”

and move towards:

“How does the process operate, what evidence demonstrates this, and what happens when the control does not work as expected?”

1. Documentation Is Only the Starting Point

Consider a simple example.

An organization has an approved:

Information Security Policy

The policy states that information security requirements must be followed by employees and relevant third parties.

During the internal audit, the auditor verifies:

Policy is approved

Policy has a version number

Policy has an effective date

Policy is available to employees

Management approval is available

All checks are satisfactory.

Can the auditor conclude that information security requirements are effectively implemented?

Not yet.

The auditor should consider how the policy is translated into actual practices.

For example:

Are employees aware of their responsibilities?

Are relevant procedures implemented?

Are access controls operating?

Are incidents being reported?

Are exceptions being managed?

Are security requirements included in onboarding?

Are corrective actions tracked?

Is evidence available that the defined processes actually operate?

A document demonstrates that a requirement has been established.

It does not automatically demonstrate that the requirement is working.

2. Start With the ISMS Objective

Before testing an ISO 27001 control, understand what the organization is trying to achieve through the ISMS.

A useful audit sequence is:

Context → Risk → Objective → Control → Implementation → Evidence → Effectiveness → Improvement

This helps the auditor maintain a risk-based perspective.

For example:

Risk: Unauthorized access to sensitive information

Control objective: Ensure access is authorized and appropriate.

Control: Periodic user-access review.

Evidence: Access review records, user population, exceptions and remediation records.

Audit question:

Does the evidence demonstrate that inappropriate access is identified and addressed within the defined process?

This is much stronger than simply checking whether an access-review document exists.

3. Verify the Audit Scope First

One of the most overlooked areas in an internal audit is the relationship between the audit scope and the evidence being tested.

Before starting detailed testing, establish:

ISMS scope
Relevant business units
Locations
Processes
Applications
Information assets
Supporting technology
Relevant interested-party requirements
Applicable legal and regulatory requirements

Suppose the ISMS scope includes a critical business application.

The auditor should not limit the assessment to the application's policy documentation.

Depending on the control and audit scope, relevant areas may include:

Application access
Change management
Logging
Backup
Incident management
Vulnerability management
Third-party dependencies
Business continuity
Data protection

Important principle

Do not test a control in isolation when its effectiveness depends on other processes or supporting controls.

4. Connect Risk to Control

A good internal audit should be able to trace a logical path:

Risk → Control → Evidence → Test → Result → Conclusion

For example:

Element	Example
Risk	Unauthorized privileged access
Control	Periodic privileged-access review
Objective	Ensure privileged access remains authorized
Evidence	Privileged-user list and review records
Test	Verify population, reviewer, frequency, exceptions and remediation
Result	Exceptions identified and reviewed
Conclusion	Evidence supports the defined control objective, subject to scope and sample

This approach helps prevent the audit from becoming a checklist exercise.

5. Review the Statement of Applicability Carefully

The Statement of Applicability is an important part of the ISMS documentation.

However, an auditor should not treat the presence of an SoA as evidence that the selected controls are effective.

For relevant controls, consider:

Is the control applicable to the organization's risks?
Is the stated justification reasonable?
Is the control actually implemented?
Is the implementation consistent with the organization's processes?
Is supporting evidence available?
Are related procedures and responsibilities defined?
Are exceptions or limitations understood?
Does actual practice align with what the organization says it has implemented?

For example, an SoA may indicate that a particular control is implemented.

The internal audit should then ask:

“Show me how this control is implemented and how you know it is working.”

6. Test the Process, Not Just the Policy

Consider a policy requiring periodic access reviews.

A document-based audit might verify:

Policy available → Yes

Procedure available → Yes

Access-review template available → Yes

Conclusion → Compliant

A more meaningful audit would test:

User population → Review performed → Reviewer authorization → Exceptions → Remediation → Closure

For example:

Step 1 — Obtain the population

Determine which users should have been included.

Step 2 — Verify the review

Check whether the review was actually performed.

Step 3 — Verify responsibility

Confirm that the designated reviewer performed or approved the review.

Step 4 — Examine exceptions

Determine whether inappropriate or obsolete access was identified.

Step 5 — Trace remediation

Select relevant exceptions and verify whether access was subsequently corrected.

Step 6 — Verify closure

Determine whether remediation was appropriately completed and documented.

Now the auditor has tested the control lifecycle, rather than merely checking documentation.

7. Evidence Should Cover the Audit Period

Another common weakness is relying on evidence from a single date.

Suppose an organization provides a screenshot dated:

30 June 2026

The audit period covers:

1 July 2025 – 30 June 2026

The screenshot may demonstrate the configuration on 30 June.

But does it demonstrate that the same configuration existed throughout the audit period?

Not necessarily.

Depending on the control, the auditor may need:

Historical records
Multiple samples
Change records
System-generated reports
Review records
Tickets
Logs
Approvals

Practical question

“Does this evidence demonstrate the condition at one point in time, or does it demonstrate operation throughout the period being assessed?”

This distinction can materially affect the audit conclusion.

8. Interview the Control Owner

Documents and system evidence are important, but discussions with process owners can reveal how the control actually works.

For example, ask:

Who performs the control?

What triggers the activity?

How frequently is it performed?

What happens when an exception is identified?

Who approves the exception?

What happens if the activity is missed?

Where is the evidence retained?

Who reviews the results?

How are overdue actions escalated?

The answers should then be corroborated with appropriate evidence.

Inquiry alone may not be sufficient to establish that a control operated.

A useful principle is:

Ask → Understand → Corroborate → Test → Conclude

9. Look for the Exception Process

A mature control is not necessarily one where exceptions never occur.

A mature process should have a defined mechanism for identifying and handling exceptions.

For example:

Control performed

↓

Exception identified

↓

Owner assigned

↓

Risk evaluated

↓

Corrective action

↓

Management review / escalation

↓

Closure

An auditor should examine whether this process actually operates.

Example

A quarterly access review identifies three users with inappropriate access.

The auditor should not stop at:

“Access review completed.”

The next questions are:

Were the three users identified?
Was the risk assessed?
Was access removed?
Who approved the remediation?
How quickly was it completed?
Is evidence of removal available?
Was the exception formally closed?

This is where control effectiveness becomes visible.

10. Don't Ignore Management of Change

A control can be effective today but may not have been effective throughout the audit period.

Changes to:

Applications
Infrastructure
Processes
Vendors
Organizational structure
Security technologies
Access models
Business processes

can affect control effectiveness.

Therefore, internal auditors should consider whether significant changes occurred during the audit period.

For example:

An organization migrated a critical application to a new platform during the year.

The auditor should consider whether:

Access controls were reassessed
Security requirements were incorporated
Risks were reassessed where appropriate
Relevant testing was performed
New responsibilities were defined
Evidence exists for the post-migration environment

A control that worked in the old environment should not automatically be assumed to work in the new one.

11. Use Sampling Intelligently

Sampling is often necessary because testing every transaction, user or event may not be practical.

However, sampling should be connected to the control and audit objective.

Before selecting samples, understand:

Population

What is the complete population?

Period

What period is being tested?

Frequency

How often should the control operate?

Risk

What could go wrong?

Sample selection

Why were these items selected?

For example, if a control operates monthly for twelve months, testing one month may provide limited insight into recurring operation.

The appropriate approach depends on the audit scope, control characteristics, risk and audit methodology.

Remember:

Sampling is not simply about selecting a number. It is about obtaining sufficient evidence to support the audit conclusion.

12. Trace One Transaction Through the Control

For many operational controls, one of the most effective techniques is to follow an item through the complete process.

For example, consider a critical application change.

Trace:

Change Request → Risk/Impact Assessment → Approval → Testing → Implementation → Validation → Closure

This can reveal gaps that individual documents may not show.

For example:

Change request exists
Approval exists
Testing evidence exists
Implementation occurred

But:

Was the implemented change actually the approved change?

A trace-based approach can help answer that question.

13. Look for Evidence From Different Sources

A stronger audit conclusion often comes from corroborating evidence.

For example:

Evidence Source	What It May Demonstrate
Policy	Defined requirement
Procedure	Defined process
System report	Actual system state/activity
Ticket	Operational activity
Approval	Authorization
Log	Recorded event
Interview	Process understanding
Sample testing	Actual operation
Remediation record	Exception handling

If multiple independent sources support the same conclusion, the auditor can have greater confidence in the assessment.

However, the relevance and reliability of each evidence source should still be considered.

14. What If the Control Works but Evidence Is Weak?

This is an important audit situation.

Suppose a process owner states:

“The access review is performed every quarter.”

But the organization cannot produce sufficient records for one or more review periods.

The auditor should distinguish between:

Control operation

Did the activity actually occur?

Evidence retention

Was sufficient evidence retained?

Auditability

Can the organization demonstrate compliance when required?

These are related but not always identical questions.

The auditor should establish the facts before determining the nature and significance of the finding.

This avoids making an unsupported conclusion such as:

“Control was not performed.”

when the available facts only demonstrate:

“Sufficient evidence could not be established.”

That difference matters.

15. Write Findings Based on the Actual Gap

A strong internal-audit observation should describe the specific control weakness.

Avoid vague statements such as:

“Access control is not effective.”

Instead, describe what was actually identified.

For example:

The organization has defined periodic user-access reviews; however, evidence demonstrating timely closure of identified access exceptions was not consistently available for the sampled review periods.

Then consider:

Risk

Unresolved access exceptions may result in inappropriate access remaining active beyond the required period.

Recommendation

Strengthen exception management by defining:

Ownership
Remediation timelines
Escalation requirements
Closure criteria
Periodic monitoring
Evidence-retention requirements

This creates a finding that management can actually act upon.

16. Ask “Why?” Before Raising a Finding

When a control gap is identified, don't immediately stop at the first symptom.

Use a simple “Why?” approach.

Example:

Finding: Access exception was not closed.

Why?

No assigned owner.

Why?

The access-review process does not define exception ownership.

Why?

The procedure focuses on review completion but does not define exception management.

Now the auditor has identified a possible process-design weakness, rather than merely reporting an individual overdue item.

This can make the recommendation much more useful.

17. Common ISO 27001 Internal Audit Mistakes

Mistake 1: Treating the audit as a document review

Documentation is important, but it is only part of the assessment.

Mistake 2: Testing only current configuration

Current state may not demonstrate historical operation.

Mistake 3: Accepting management explanation without corroboration

Inquiry should generally be supported by appropriate evidence.

Mistake 4: Ignoring exceptions

Exceptions often reveal how well the control actually works.

Mistake 5: Testing controls without understanding the risk

Without understanding the objective, testing can become mechanical.

Mistake 6: Writing overly broad findings

A finding should identify the specific condition and associated risk.

Mistake 7: Confusing missing evidence with confirmed control failure

The auditor should establish what the available evidence actually demonstrates.

Mistake 8: Focusing only on individual controls

Some controls depend on supporting processes and other controls.

The auditor should consider relevant dependencies.

18. A Practical Internal Audit Workflow

A simple workflow for conducting an effective ISO 27001 internal audit is:

Before the Audit

Understand Scope → Review Risks → Understand Controls → Prepare Test Approach

During the Audit

Interview → Inspect → Sample → Test → Trace → Corroborate → Record Evidence

When Exceptions Are Found

Identify → Validate → Assess Risk → Trace Remediation → Determine Impact

At Conclusion

Evaluate Evidence → Determine Conformity/Nonconformity as applicable → Document Finding → Recommend Improvement → Follow Up

This creates a structured audit process without turning the audit into a purely checklist-driven exercise.

19. A Simple Internal Audit Test Sheet

A practical audit worksheet can contain:

Field	Example
Audit Area	Access Management
Risk	Unauthorized access
Control	Periodic access review
Objective	Ensure access remains appropriate
Owner	Application Owner
Frequency	Quarterly
Population	Application users
Evidence	Access review reports
Test Procedure	Verify population, frequency, authorization, exceptions and remediation
Sample	Selected review periods/users
Exceptions	Access exceptions identified
Remediation	Access removed
Evidence Gap	Closure evidence unavailable for one sample
Conclusion	Further assessment / finding based on applicable criteria

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

20. The Real Purpose of an Internal Audit

An internal audit should not exist merely to produce a statement that:

“All required documents are available.”

Its greater value is helping the organization understand:

Where controls are working
Where controls are weak
Where evidence is insufficient
Where risks may remain
Where processes need improvement
Whether corrective actions are actually addressing the underlying issue

A useful internal audit therefore becomes a feedback mechanism for improving the ISMS, rather than simply a compliance checkpoint.

21. The Auditor’s Final Question

After completing the testing, the auditor should be able to answer:

“What evidence did I examine, what did I actually test, what exceptions did I identify, and what does the evidence allow me to conclude?”

If the answer is clear, traceable and supported by appropriate evidence, the audit conclusion becomes much stronger.

The goal is not to prove that everything is perfect.

The goal is to provide an objective, evidence-based assessment of whether the ISMS and relevant controls are operating as intended and where improvement is needed.

Key Takeaways

An ISO 27001 internal audit should go beyond documentation review.
Start with scope, risk and control objectives.
Do not assume that an SoA or policy proves implementation.
Test actual processes and control operation.
Consider the audit period, not only the current state.
Establish the population before selecting samples.
Use inquiry together with appropriate corroborating evidence.
Follow exceptions through remediation and closure.
Distinguish evidence gaps from confirmed control failures.
Write findings around the specific control weakness and associated risk.
Look for root causes rather than reporting only symptoms.
Use audit results as an opportunity for continual improvement.

The key question is:

“Does the evidence demonstrate that the ISMS control is actually working as intended, within the scope and period being audited?”

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: ISO 27001 Internal Audit, ISO 27001 Audit, Information Security Audit, Control Effectiveness, ISMS Audit, Audit Evidence, Cyber GRC