An ISO/IEC 27001 Internal Audit is a systematic review of an organization’s Information Security Management System (ISMS) to determine whether it is properly implemented, maintained, and operating as intended.

The purpose is not simply to check whether policies exist. An effective internal audit verifies:

• Whether the ISMS meets ISO/IEC 27001 requirements
• Whether identified risks are being managed
• Whether selected controls are actually implemented
• Whether controls are operating effectively
• Whether employees follow documented processes
• Whether objective evidence exists
• Whether previous audit findings have been addressed
• Whether the ISMS continues to support the organization’s business and security objectives

ISO/IEC 27001:2022 uses a risk-based approach. Therefore, the internal audit should connect business context → risks → risk treatment → controls → implementation → evidence → effectiveness.

---

1. Internal Audit Process

A practical ISO 27001 internal audit can follow this sequence:

Audit Planning → Document Review → Interviews → Evidence Sampling → Technical Verification → Findings → Corrective Actions → Follow-up

For a startup, the audit does not need to become unnecessarily bureaucratic. The auditor should focus on the organization’s actual risks, scope, systems, people, suppliers, and applicable controls.

---

2. ISO 27001 Internal Audit Checklist

A. Context of the Organization — Clause 4

Audit Question	Evidence to Check	Result
Has the organization identified internal and external issues relevant to information security?	Context analysis / ISMS document	☐ C ☐ NC ☐ OFI
Have relevant interested parties been identified?	Interested-party register	☐ C ☐ NC ☐ OFI
Have applicable requirements from customers, regulators and contracts been identified?	Legal/contractual requirements register	☐ C ☐ NC ☐ OFI
Is the ISMS scope clearly defined?	ISMS Scope document	☐ C ☐ NC ☐ OFI
Does the scope cover relevant people, processes, technology and locations?	Scope + asset/process review	☐ C ☐ NC ☐ OFI
Is the ISMS scope consistent with the organization’s actual operations?	Interviews / system inventory	☐ C ☐ NC ☐ OFI

Auditor focus

Do not simply read the scope document. Compare it with reality.

Example:
If the scope says the SaaS platform is covered but the company has excluded its production AWS environment, investigate whether the scope is actually appropriate.

---

3. Leadership — Clause 5

Audit Question	Evidence to Check	Result
Has top management demonstrated commitment to the ISMS?	Management meeting records	☐ C ☐ NC ☐ OFI
Has an information security policy been approved?	Approved policy	☐ C ☐ NC ☐ OFI
Is the security policy communicated to relevant employees?	Training / acknowledgement records	☐ C ☐ NC ☐ OFI
Are information security responsibilities defined?	RACI / role descriptions	☐ C ☐ NC ☐ OFI
Are ISMS responsibilities assigned to appropriate personnel?	Appointment records / interviews	☐ C ☐ NC ☐ OFI
Are security objectives established?	Security objectives / KPI records	☐ C ☐ NC ☐ OFI
Does management review ISMS performance?	Management review minutes	☐ C ☐ NC ☐ OFI

Auditor test

Ask management:

“What are the organization’s top three information security risks, and what are you doing about them?”

If management cannot answer, investigate whether the ISMS is actually integrated into management decision-making.

---

4. Planning — Clause 6

Risk Assessment

Audit Question	Evidence to Check	Result
Is there a documented risk assessment methodology?	Risk methodology	☐ C ☐ NC ☐ OFI
Are information security risks identified?	Risk register	☐ C ☐ NC ☐ OFI
Are assets, processes and threats considered?	Risk assessment records	☐ C ☐ NC ☐ OFI
Are likelihood and impact assessed consistently?	Risk scoring methodology	☐ C ☐ NC ☐ OFI
Are risk acceptance criteria defined?	Risk methodology	☐ C ☐ NC ☐ OFI
Are risks prioritized?	Risk register	☐ C ☐ NC ☐ OFI
Are risk owners assigned?	Risk register	☐ C ☐ NC ☐ OFI
Is the risk assessment periodically reviewed?	Review records	☐ C ☐ NC ☐ OFI

Risk Treatment

Audit Question	Evidence to Check	Result
Is there a risk treatment plan?	Risk Treatment Plan	☐ C ☐ NC ☐ OFI
Are treatment decisions documented?	Risk register / treatment plan	☐ C ☐ NC ☐ OFI
Are controls selected based on identified risks?	Risk-to-control mapping	☐ C ☐ NC ☐ OFI
Are residual risks evaluated?	Updated risk register	☐ C ☐ NC ☐ OFI
Are residual risks formally accepted where required?	Risk acceptance records	☐ C ☐ NC ☐ OFI
Is the Statement of Applicability consistent with risk treatment?	SoA + risk register	☐ C ☐ NC ☐ OFI

---

5. Statement of Applicability — SoA

The auditor should specifically verify the relationship between the Risk Assessment, Risk Treatment Plan and SoA.

Audit Question	Evidence to Check	Result
Is the SoA maintained?	Current SoA	☐ C ☐ NC ☐ OFI
Are necessary controls identified?	SoA	☐ C ☐ NC ☐ OFI
Is each control’s applicability justified?	SoA justification	☐ C ☐ NC ☐ OFI
Are implementation statuses accurate?	SoA + evidence	☐ C ☐ NC ☐ OFI
Are applicable controls actually implemented?	Evidence sampling	☐ C ☐ NC ☐ OFI
Are excluded controls supported by appropriate justification?	SoA	☐ C ☐ NC ☐ OFI
Are necessary controls outside Annex A identified where applicable?	Internal controls / contractual requirements	☐ C ☐ NC ☐ OFI
Does the SoA remain aligned with current risks and technology?	Risk register / architecture / SoA	☐ C ☐ NC ☐ OFI

The SoA should not be treated as a simple “93 controls checklist.” ISO/IEC 27001 uses risk treatment to determine necessary controls, with Annex A serving as a comparison point to help ensure necessary controls have not been overlooked.

---

6. Support — Clause 7

Resources

• ☐ Adequate ISMS resources are available
• ☐ Security personnel have appropriate responsibilities
• ☐ Required security tools are available
• ☐ Security budget/resources are appropriate

Competence

• ☐ Competence requirements are defined
• ☐ Employees performing security-related activities are competent
• ☐ Relevant training records are maintained
• ☐ Technical/security certifications are maintained where required

Awareness

Check whether employees understand:

• ☐ Information security policy
• ☐ Their security responsibilities
• ☐ Incident reporting process
• ☐ Acceptable use requirements
• ☐ Password/MFA requirements
• ☐ Data handling requirements
• ☐ Consequences of violating security requirements

Communication

• ☐ Internal security communication process exists
• ☐ External security communication responsibilities are defined
• ☐ Security incidents can be escalated appropriately

Documented Information

• ☐ Required ISMS documents are controlled
• ☐ Document versions are identifiable
• ☐ Approvals are documented
• ☐ Obsolete documents are controlled
• ☐ Records are protected from unauthorized modification
• ☐ Evidence can be retrieved when required

---

7. Operation — Clause 8

Operational Planning and Control

Check	Result
ISMS processes are being performed as planned	☐ C ☐ NC ☐ OFI
Operational security procedures are followed	☐ C ☐ NC ☐ OFI
Changes to security processes are controlled	☐ C ☐ NC ☐ OFI
Outsourced processes are controlled	☐ C ☐ NC ☐ OFI
Security requirements are incorporated into relevant operations	☐ C ☐ NC ☐ OFI

Risk Assessment During Operations

• ☐ Risk assessments are performed at defined intervals
• ☐ Significant changes trigger risk reassessment
• ☐ New systems are evaluated for security risks
• ☐ Major suppliers are evaluated
• ☐ New regulatory/customer requirements are assessed

Risk Treatment During Operations

• ☐ Treatment actions are being completed
• ☐ Delayed actions are tracked
• ☐ Risk owners are following up
• ☐ Residual risks are reviewed
• ☐ Accepted risks remain within defined acceptance criteria

---

8. Performance Evaluation — Clause 9

Monitoring and Measurement

Check whether the organization measures relevant security performance.

Examples:

• Security incidents
• Vulnerability remediation
• Backup success rate
• Security training completion
• Access review completion
• Penetration testing
• Supplier reviews
• Security objectives
• Risk treatment progress
• Internal audit findings

Audit Question	Evidence	Result
Are security KPIs defined?	KPI dashboard	☐ C ☐ NC ☐ OFI
Are KPIs actually measured?	Reports	☐ C ☐ NC ☐ OFI
Are results reviewed?	Management/security meetings	☐ C ☐ NC ☐ OFI
Are adverse trends investigated?	Corrective actions	☐ C ☐ NC ☐ OFI

---

9. Internal Audit Program

The auditor should verify that the organization has an effective internal audit program.

Check:

• ☐ Internal audit program established
• ☐ Audit frequency defined
• ☐ Audit scope defined
• ☐ Audit criteria defined
• ☐ Auditors are appropriately competent
• ☐ Auditor independence/objectivity is considered
• ☐ Audit results are documented
• ☐ Findings are communicated
• ☐ Corrective actions are tracked
• ☐ Previous findings are followed up

Important test

If someone audits their own work, check whether the organization has taken appropriate steps to maintain objectivity and impartiality.

---

10. Management Review

Verify that management reviews the ISMS at planned intervals.

Check for:

• ☐ Previous management review actions
• ☐ Changes in internal/external issues
• ☐ Changes in interested-party requirements
• ☐ Information security performance
• ☐ Nonconformities and corrective actions
• ☐ Monitoring results
• ☐ Internal audit results
• ☐ Achievement of security objectives
• ☐ Risk assessment results
• ☐ Risk treatment status
• ☐ Opportunities for improvement
• ☐ Resource requirements
• ☐ Decisions and actions from management review

---

11. Improvement — Clause 10

Nonconformity and Corrective Action

For each finding, verify:

• ☐ Nonconformity identified
• ☐ Immediate correction considered
• ☐ Root cause analyzed
• ☐ Corrective action defined
• ☐ Responsibility assigned
• ☐ Target date defined
• ☐ Action implemented
• ☐ Effectiveness verified
• ☐ Risk of recurrence considered
• ☐ Records maintained

---

12. Annex A Control Audit

The auditor should then sample the controls identified as necessary in the organization’s SoA.

The 93 Annex A controls in ISO/IEC 27001:2022 are organized into four themes:

1. Organizational controls
2. People controls
3. Physical controls
4. Technological controls

Example control testing

Area	Auditor Question	Example Evidence
Asset management	Can the organization identify its important information assets?	Asset inventory
Access control	Are users given only the access they require?	IAM/access review
Privileged access	Are administrator privileges controlled?	AWS IAM/PAM records
Supplier security	Are important suppliers assessed?	Supplier assessments
Incident management	Can employees report security incidents?	Incident tickets
Backup	Are backups performed and tested?	Backup logs/test records
Vulnerability management	Are vulnerabilities identified and remediated?	Vulnerability reports
Logging	Are security-relevant events logged?	SIEM/CloudTrail logs
Monitoring	Are security events monitored?	Monitoring alerts
Secure development	Are security requirements integrated into development?	SDLC records
Change management	Are production changes authorized?	Change tickets/GitHub PRs
Cryptography	Is sensitive information protected appropriately?	Encryption configuration
Business continuity	Can critical services continue after disruption?	BCP/DR test
Physical security	Are office facilities and equipment protected?	Access records
Personnel security	Are security responsibilities addressed during onboarding/offboarding?	HR records

---

13. Evidence Sampling

An internal audit should not stop at asking:

“Do you have a policy?”

The better question is:

“Show me how this requirement operates in practice.”

Example — Access Control

Policy:
Employees must receive access based on business requirements.

Audit testing:

1. Select 5 employees.
2. Review their current system access.
3. Check their job responsibilities.
4. Compare access against approved requests.
5. Check manager approval.
6. Check whether excessive privileges exist.
7. Check recent joiner/mover/leaver records.
8. Check periodic access review evidence.

This tests implementation and effectiveness, rather than simply the existence of a document.

---

14. AWS SaaS Startup Internal Audit Example

Consider a SaaS company hosted on AWS.

Systems

• AWS IAM
• EC2/ECS
• Amazon RDS
• Amazon S3
• CloudFront
• AWS WAF
• CloudTrail
• CloudWatch
• GitHub
• Employee laptops

The auditor could select the following sample:

AWS IAM

Check:

• ☐ MFA enabled
• ☐ Privileged accounts identified
• ☐ Least-privilege permissions
• ☐ Former employees removed
• ☐ Access reviews performed
• ☐ Service accounts controlled
• ☐ Administrative activity logged

S3

Check:

• ☐ Public access blocked where required
• ☐ Bucket permissions reviewed
• ☐ Encryption configured
• ☐ Sensitive data identified
• ☐ Access logging/monitoring appropriate
• ☐ Data retention/deletion requirements addressed

RDS

Check:

• ☐ Encryption
• ☐ Backup configuration
• ☐ Backup restoration testing
• ☐ Network restrictions
• ☐ Administrative access
• ☐ Monitoring
• ☐ Vulnerability/patch management

GitHub / Development

Check:

• ☐ Code repository access
• ☐ Branch protection
• ☐ Pull request approvals
• ☐ Secrets management
• ☐ Dependency scanning
• ☐ Security testing
• ☐ Production deployment authorization

---

15. Internal Audit Finding Classification

A practical audit report can classify observations as:

Conformity

Requirement is implemented and operating as expected.

Example:
Quarterly privileged-access reviews were completed and evidence was available.

Minor Nonconformity

A requirement is not fully met, but the issue does not indicate a complete breakdown of the relevant system/process.

Example:
One quarterly access review was completed 20 days late without documented justification.

Major Nonconformity

A significant failure exists that affects the ability of the ISMS to achieve its intended outcomes, or indicates a substantial breakdown of a requirement/process.

Example:
The organization has identified critical risks but has no functioning risk treatment process or evidence that those risks are being managed.

Opportunity for Improvement

The organization meets the requirement, but there is a reasonable opportunity to improve effectiveness or efficiency.

---

16. Internal Audit Finding Format

Every finding should contain enough information for management to understand and correct it.

Finding ID: IA-2026-001

Requirement:
Applicable ISO 27001 requirement / internal requirement.

Observation:
What the auditor actually observed.

Objective Evidence:
The evidence supporting the finding.

Finding:
What requirement was not fully met.

Risk/Impact:
Potential consequence.

Root Cause:
Why the issue occurred.

Corrective Action:
What the organization plans to do.

Owner:
Responsible person.

Target Date:
Expected completion date.

Verification:
How effectiveness will be checked.

---

17. Internal Audit Report Structure

A professional ISO 27001 internal audit report can contain:

1. Audit objective
2. Audit scope
3. Audit criteria
4. Audit dates
5. Audit team
6. Departments/functions audited
7. Systems and locations sampled
8. Methodology
9. Summary of results
10. Conformities
11. Nonconformities
12. Opportunities for improvement
13. Evidence reviewed
14. Corrective actions
15. Conclusion
16. Follow-up requirements

---

18. Final Internal Audit Checklist

Before closing the audit, confirm:

ISMS

☐ Scope is appropriate
☐ Context is reviewed
☐ Interested parties identified
☐ Security policy approved
☐ Objectives established

Risk

☐ Risk methodology exists
☐ Risks identified
☐ Risk owners assigned
☐ Risk treatment completed/tracked
☐ Residual risks reviewed

SoA

☐ SoA is current
☐ Applicability justified
☐ Implementation status accurate
☐ SoA aligns with risk treatment
☐ Necessary non-Annex A controls considered

Operations

☐ Security procedures operate as documented
☐ Access controls work
☐ Suppliers are managed
☐ Incidents are handled
☐ Backups are performed/tested
☐ Vulnerabilities are managed
☐ Changes are controlled
☐ Security monitoring operates

People

☐ Joiner process works
☐ Mover process works
☐ Leaver process works
☐ Security awareness is performed
☐ Responsibilities are understood

Technology

☐ Systems are inventoried
☐ Privileged access is controlled
☐ MFA is implemented where required
☐ Logging operates
☐ Monitoring operates
☐ Encryption is appropriately implemented
☐ Secure development practices operate
☐ Security testing is performed

Performance

☐ Security KPIs are monitored
☐ Internal audits are performed
☐ Management reviews are conducted
☐ Findings are tracked
☐ Corrective actions are verified

Improvement

☐ Nonconformities are recorded
☐ Root causes are analyzed
☐ Corrective actions are implemented
☐ Effectiveness is verified
☐ Continual improvement opportunities are identified

---

The Key Principle

A good ISO 27001 internal audit should move through this chain:

Requirement → Risk → Control → Process → Evidence → Effectiveness → Finding

For example:

Risk: Unauthorized AWS production access
↓
Control: Privileged access management
↓
Process: AWS admin access approval and quarterly review
↓
Evidence: IAM configuration + approval tickets + access review
↓
Effectiveness: Sample users and verify actual permissions
↓
Finding: Identify any gap and determine corrective action

This approach makes the internal audit much more valuable than simply checking whether 93 Annex A controls have a policy document.