ISO 27001 Internal Audit: Planning, Conducting, and Reporting

Internal audits are one of the most critical mechanisms in the ISO 27001 framework. They provide an independent evaluation of whether your Information Security Management System (ISMS) conforms to the requirements of the standard and your own documented policies, and whether the ISMS is effectively implemented and maintained. Without internal audits, your ISMS operates in a blind spot — you have no objective evidence that what you designed is what you are actually doing.

Many SaaS companies treat internal audits as a checkbox exercise — a once-a-year rush through a generic checklist that produces a report no one reads. This misses the point entirely. A well-conducted internal audit is the single most effective tool for identifying weaknesses before your certification auditor finds them, for driving continual improvement, and for giving management the information they need to make informed decisions about security investments.

This guide covers everything SaaS teams need to know about ISO 27001 internal audits: the Clause 9.2 requirements, the difference between internal and certification audits, how to plan an audit program, how to conduct individual audits, how to classify and report findings, and how to manage corrective actions through to closure.

What Clause 9.2 Requires

Clause 9.2 is the normative requirement for internal audits. It is not lengthy, but every word matters.

Clause 9.2.1 — General

The organization shall conduct internal audits at planned intervals to provide information on whether the ISMS:

a) Conforms to the organization’s own requirements for its ISMS b) Conforms to the requirements of ISO 27001 c) Is effectively implemented and maintained

This establishes two dimensions of audit assessment. First, conformity — does the ISMS match what the standard requires and what you documented? Second, effectiveness — is the ISMS actually achieving its intended outcomes? A policy might exist (conformity), but if no one follows it (ineffectiveness), the audit must capture that.

Clause 9.2.2 — Internal Audit Programme

The organization shall:

a) Plan, establish, implement, and maintain an audit programme, including frequency, methods, responsibilities, planning requirements, and reporting b) Define the audit criteria and scope for each audit c) Select auditors and conduct audits that ensure objectivity and impartiality of the audit process d) Ensure that the results of the audits are reported to relevant management e) Retain documented information as evidence of the audit programme and the audit results

This clause drives several concrete requirements:

• You need an audit programme (not just individual audits) that covers the entire ISMS over a defined cycle
• Each audit needs defined criteria (what you are auditing against) and scope (what you are auditing)
• Auditors must be objective and impartial — they cannot audit their own work
• Results must be reported to management
• You must retain evidence of the programme and results

Internal Audit vs. Certification Audit

Understanding the distinction between internal and certification audits helps SaaS teams approach each correctly.

Internal Audit

• Conducted by or on behalf of the organization itself
• Purpose: Evaluate ISMS conformity and effectiveness, identify improvement opportunities
• Frequency: At planned intervals defined by the organization (typically annually, covering all ISMS areas over a 12-month cycle)
• Auditors: Internal staff, contracted consultants, or a combination — must be independent of the area being audited
• Output: Internal audit report with findings and recommendations
• Consequences: Findings drive corrective actions and improvement through management review

Stage 1 Certification Audit (Document Review)

• Conducted by an accredited certification body
• Purpose: Assess whether the ISMS documentation is adequate and whether the organization is ready for the Stage 2 audit
• Frequency: Once during initial certification, then as part of surveillance or recertification cycles
• Auditors: Lead auditors from the certification body
• Output: Stage 1 report identifying documentation gaps and areas of concern
• Consequences: Must address significant gaps before proceeding to Stage 2

Stage 2 Certification Audit (Implementation Audit)

• Conducted by the same certification body
• Purpose: Evaluate whether the ISMS is implemented and operating effectively
• Frequency: Once during initial certification, annually during surveillance, every three years for recertification
• Auditors: Lead auditors from the certification body
• Output: Audit report with nonconformities and the certification decision
• Consequences: Major nonconformities must be resolved before certification is granted

How Internal Audits Support Certification

Your internal audit is your dress rehearsal for the certification audit. It tests the same things the certification auditor will test, using similar methods. The findings from your internal audit give you time to fix problems before the certification auditor discovers them.

Certification auditors will also review your internal audit programme and results as part of their assessment. They are checking that:

• You have an active internal audit programme
• It covers the full scope of the ISMS
• Auditors were competent and independent
• Findings were identified and addressed through corrective actions
• Results were reported to management

If your internal audit programme is weak, superficial, or non-existent, certification auditors will flag this as a significant nonconformity because it indicates that Clause 9.2 is not being met.

Audit Programme Planning

An audit programme is the overarching plan that ensures every part of your ISMS is audited over a defined cycle. Individual audits are scheduled events within that programme.

Defining the Audit Cycle

Most organizations use a 12-month audit cycle aligned with their ISMS annual review. Within that cycle, every clause of ISO 27001 (Clauses 4-10) and every applicable Annex A control must be audited at least once.

Approach 1: Single comprehensive audit. Audit the entire ISMS in one event, typically over 3-5 days. This works well for smaller SaaS companies (under 100 employees) with a tightly scoped ISMS.

Advantages: Simple to schedule, provides a complete picture at a single point in time. Disadvantages: Resource-intensive, disruptive, findings arrive all at once which can overwhelm the corrective action process.

Approach 2: Rolling audit programme. Divide the ISMS into audit areas and schedule separate audits throughout the year. For example:

• Q1: Access control (A.5.15-A.5.18, A.8.2-A.8.5), Human resource security (A.6.1-A.6.5)
• Q2: Incident management (A.5.24-A.5.28), Business continuity (A.5.29-A.5.30)
• Q3: Operations security (A.8.6-A.8.16), Cryptography (A.8.24), Network security (A.8.20-A.8.23)
• Q4: Governance (Clauses 4-7), Risk management (Clause 6, A.5.1-A.5.8), Supplier management (A.5.19-A.5.23)

Advantages: Distributes the effort and disruption across the year, allows corrective actions to be addressed continuously, provides more current evidence. Disadvantages: More scheduling complexity, requires consistent auditor availability throughout the year.

Approach 3: Risk-based audit programme. Prioritize audit areas based on risk: areas with higher risk, recent changes, or previous nonconformities receive more audit attention (higher frequency, deeper scope). Lower-risk areas may be audited less frequently but still within the cycle.

SaaS recommendation: For most SaaS companies pursuing initial certification, start with a single comprehensive audit scheduled 2-3 months before your Stage 2 certification audit. This gives you enough time to address findings before the certification auditor arrives. After initial certification, transition to a rolling programme that spreads the workload across the year.

Risk-Based Prioritization

Not all ISMS areas carry equal risk. Your audit programme should reflect this by allocating more audit time and depth to higher-risk areas.

Higher-risk areas (more audit time and depth):

• Access control — The most common source of audit findings
• Incident management — Directly impacts customer trust and regulatory obligations
• Risk assessment and treatment — The foundation of the ISMS; weaknesses here undermine everything
• Supplier management — Increasing scrutiny due to supply chain attacks
• Areas that have changed significantly since the last audit
• Areas where previous audits identified nonconformities

Lower-risk areas (standard audit coverage):

• Physical security (for cloud-only SaaS companies with minimal physical infrastructure)
• Document control (important but typically stable once established)
• Areas that have not changed and had no prior findings

Audit Programme Documentation

Document your audit programme as a formal plan. It should include:

• The audit cycle period (e.g., January 2026 through December 2026)
• All planned audits with target dates
• The scope (ISMS areas/controls) covered by each audit
• The audit criteria for each audit
• Assigned auditors
• The overall objective of the programme
• Reference to the previous cycle’s results and how they influenced current priorities

This document is evidence that you are meeting Clause 9.2.2(a). Certification auditors will request it.

Auditor Competence and Independence

Who Can Conduct Internal Audits?

ISO 27001 requires that auditors are objective, impartial, and competent. It does not require that auditors hold specific certifications or qualifications. However, they must have sufficient knowledge of:

• ISO 27001 requirements (Clauses 4-10 and Annex A)
• Audit principles and techniques
• The organization’s ISMS and its context
• Information security concepts relevant to the areas being audited

Independence and Impartiality

The core rule: auditors must not audit their own work. The person who designed a control, wrote a policy, or manages a process cannot audit that control, policy, or process. This does not mean auditors must be entirely external to the organization — it means they must be independent of the specific area being audited.

Options for achieving independence in SaaS companies:

Internal cross-auditing. Team members audit areas outside their responsibility. The engineering lead audits HR security. The operations manager audits access control. The compliance manager audits incident response (assuming they did not design the incident response process).

Advantages: No external cost, auditors understand the organization, findings are actionable. Challenges: Requires multiple people with audit skills, potential for unconscious bias among colleagues.

Contracted consultant or audit firm. Engage an external consultant to conduct or lead the internal audit. This provides clear independence and typically brings experienced audit skills.

Advantages: Unquestionable independence, professional audit methodology, benchmarking against other organizations. Challenges: Cost ($5,000-$20,000+ depending on scope and complexity), less organizational context, requires coordination.

Hybrid approach. An external lead auditor conducts the audit with internal staff serving as co-auditors or guides. This combines independence with organizational knowledge.

SaaS recommendation: For initial certification, consider using an external consultant for at least the first internal audit. They bring audit methodology expertise and can mentor internal staff who will conduct future audits. For subsequent years, transition to an internal cross-auditing model supplemented by external resources for high-risk areas.

Auditor Training

If you plan to use internal staff for audits, invest in their development:

• ISO 27001 internal auditor training course (typically 2 days, available from BSI, PECB, IRCA-certified providers) — This is the most common training investment and covers audit planning, evidence gathering, finding classification, and reporting
• ISO 19011 training — The standard for auditing management systems, which provides comprehensive guidance on audit principles and methodology
• Shadowing experienced auditors during external or certification audits to learn technique and approach

Retain training records as evidence of auditor competence. Certification auditors will verify that your internal auditors were competent.

Planning an Individual Audit

Each audit within your programme requires its own planning phase. Thorough planning is the difference between an audit that produces actionable findings and one that wastes everyone’s time.

Defining Audit Scope

The audit scope specifies exactly what will be examined. Be precise:

• Which ISMS areas/clauses/controls will be audited
• Which departments, teams, or functions will be included
• Which systems, applications, or infrastructure components are in scope
• Which locations (for distributed organizations)
• Which time period the audit covers (evidence from when to when)

Example scope statement: “This audit covers the implementation and effectiveness of access control (Annex A controls A.5.15 through A.5.18 and A.8.2 through A.8.5) across all production systems, cloud infrastructure, and corporate applications within the ISMS scope. The audit period is January 1, 2026, through March 31, 2026. The engineering, IT operations, and people operations teams are in scope.”

Defining Audit Criteria

Audit criteria are the references against which you evaluate conformity. They typically include:

• ISO 27001:2022 requirements (specific clauses)
• The organization’s ISMS documentation (policies, procedures, standards)
• The Statement of Applicability
• Applicable legal, regulatory, or contractual requirements
• Previous audit findings and corrective actions

Developing the Audit Plan

The audit plan is the operational document that structures the audit execution:

Audit objectives: What the audit aims to determine. Example: “Determine whether access control policies and procedures conform to ISO 27001 Annex A requirements and are effectively implemented across production systems.”

Audit schedule: Date(s), time(s), and locations. For a focused audit (single ISMS area), this might be a single day. For a comprehensive audit, 3-5 days.

Audit team: Lead auditor and any co-auditors or technical specialists.

Auditee contacts: The people who will participate in interviews and provide evidence. Notify them in advance with sufficient time to prepare.

Evidence request list: A preliminary list of documents, records, and system access you will need. Sending this in advance reduces delays during the audit. Example evidence requests for an access control audit:

• Current access control policy (and evidence of approval and communication)
• User access lists for all production systems
• Privileged access lists
• Access review records for the audit period
• Provisioning and deprovisioning records (sample of 10-15 from the audit period)
• Terminated employee list for the audit period
• MFA enforcement configurations
• Access-related incident records

Audit checklist: A detailed list of questions and checks organized by control or clause. This is your working tool during the audit — it ensures you cover every requirement systematically.

Preparing the Audit Checklist

An effective audit checklist translates each requirement into specific, testable questions. For each control or clause, include:

• The requirement being tested (reference the specific clause, control, or policy statement)
• The audit question(s) — what you will ask or verify
• The expected evidence — what conformity looks like
• Space for the auditor’s notes, evidence references, and preliminary finding

Example checklist entry:

Reference	Requirement	Audit Question	Expected Evidence
A.5.15 / Access Control Policy Section 4.2	Access is granted based on least privilege	How does the organization ensure that users receive only the access necessary for their role? Can you show me the RBAC model and how it is applied?	Documented RBAC model. User access records matching role definitions. No users with excessive permissions.
A.5.18 / Access Control Policy Section 6.1	Access rights are reviewed at defined intervals	Were access reviews completed per the policy schedule? Show me the review records.	Completed access review records for each scheduled review period. Documented findings and remediation.
A.8.2 / Access Control Policy Section 5	Privileged access is restricted and controlled	Who has privileged access? How is it authorized and monitored?	Documented privileged access list. Authorization records. Activity logs for privileged sessions. Quarterly review records.

Conducting the Audit

Opening Meeting

Every audit begins with an opening meeting. This sets the tone and expectations.

Attendees: The audit team, the ISMS manager or representative, and key stakeholders for the areas being audited (department heads, system owners).

Agenda:

1. Confirm the audit scope, objectives, and criteria
2. Review the audit schedule and logistics
3. Confirm key contacts and interview availability
4. Explain the audit methodology (interviews, document review, system observation, sampling)
5. Explain how findings will be classified and communicated
6. Address questions from the auditee team
7. Confirm confidentiality of audit information

SaaS tip: Keep the opening meeting concise — 20-30 minutes. Engineers and operations teams appreciate efficiency. Establish that the audit is a constructive exercise aimed at finding improvement opportunities, not a punitive review.

Evidence Gathering Methods

Auditors gather evidence through four primary methods:

1. Document review

Examine documented information (policies, procedures, records, logs) against the audit criteria. This is the foundation of every audit.

What to review:

• Policies and procedures: Are they current, approved, communicated, and aligned with ISO 27001 requirements?
• Records: Do they demonstrate that processes are being followed as documented?
• Logs: Do system logs confirm that technical controls are operating?
• Previous audit reports and corrective action records: Have prior findings been addressed?

What to look for:

• Documents that reference other documents that do not exist (broken references)
• Policies that describe processes differently from how they actually work
• Missing records for required activities (access reviews, risk assessments, management reviews)
• Outdated documents that have not been reviewed within their review period
• Approval records that are missing or incomplete

2. Interviews

Speak with personnel who perform security-relevant activities to verify that they understand and follow documented procedures.

Interview tips:

• Ask open-ended questions: “Walk me through what happens when a new employee starts” rather than “Do you follow the onboarding procedure?”
• Ask for specific examples: “Can you show me the last access review you conducted?”
• Interview at multiple levels: managers (strategy and oversight), practitioners (daily operations), and general employees (awareness and compliance)
• Listen for inconsistencies between what different people describe — these often indicate process gaps

Sample interview questions by role:

For the ISMS manager:

• How do you track ISMS performance against the security objectives?
• Walk me through the last management review — what was discussed and what actions came out of it?
• How do you ensure that all applicable Annex A controls are implemented and operating?

For engineering leads:

• How is production access managed for your team?
• What happens when a team member leaves — walk me through the deprovisioning process
• How do you handle emergency changes to production?

For general employees:

• Where would you find the information security policy?
• What would you do if you suspected a security incident?
• When did you last complete security awareness training?

3. System observation

Directly observe or verify technical controls by reviewing system configurations, dashboards, and outputs.

Examples:

• Review IAM configurations in AWS/Azure/GCP to verify MFA enforcement
• Check identity provider settings to confirm SSO configuration and conditional access policies
• Review SIEM dashboards to verify that security monitoring is active
• Examine backup configurations and verify recent backup completion logs
• Review code repository settings to confirm branch protection rules
• Check vulnerability scanner configurations and recent scan results

SaaS advantage: Most SaaS infrastructure configurations can be verified through console access or CLI commands. This makes system observation faster and more comprehensive than in traditional environments where auditors might need to physically inspect data centers.

4. Sampling

When a complete review of all records is impractical, select a representative sample. Sampling must be defined and justified.

Sampling guidance:

• For populations under 10, examine all items
• For populations of 10-50, examine at least 10 items or 25% (whichever is higher)
• For populations over 50, use statistical sampling (typically 25-30 items) or risk-based selection
• Document your sampling methodology and rationale
• Include both recent and older items in the sample period to detect trends

Common sampling scenarios:

• User provisioning records: Sample 15-20 new hire access provisioning events across the audit period
• Deprovisioning records: Sample all terminations if fewer than 10; otherwise sample 15-20 and cross-reference against active account lists
• Change management records: Sample 15-20 production deployments and verify each followed the documented change process
• Access review records: Review all scheduled access reviews (since there should only be 4 per year for quarterly reviews)

Documenting Evidence

For every check on your audit checklist, document:

• What you examined (specific document, record, system, or interview)
• What you found (factual observation, not interpretation)
• The evidence reference (document name and version, screenshot file name, interview name and date, log entry timestamp)
• Your preliminary assessment (conforming, nonconforming, observation, or requires further investigation)

Maintain an evidence file that supports every finding. If you identify a nonconformity, the evidence must be specific enough that someone who was not present at the audit could understand the gap.

Classifying Findings

Findings are the output of the audit — the gaps, weaknesses, and strengths identified through evidence gathering. How you classify findings directly affects how they are prioritized and addressed.

Major Nonconformity

A major nonconformity exists when:

• A required ISMS process is entirely absent (e.g., no risk assessment has been conducted)
• A control that is declared applicable in the Statement of Applicability is not implemented at all
• A systematic failure of a control or process affects the ISMS’s ability to achieve its intended outcomes
• Multiple related minor nonconformities that collectively indicate a systemic failure
• A clause of ISO 27001 is not being met, and the gap is significant

Example: The organization’s access control policy requires quarterly access reviews, but no access review has been conducted in the past 12 months. Access lists show multiple active accounts belonging to terminated employees.

Significance: In a certification audit, a major nonconformity must be resolved before the certificate is issued. In an internal audit, a major nonconformity requires immediate corrective action with priority attention from management.

Minor Nonconformity

A minor nonconformity exists when:

• A control or process is implemented but has isolated gaps or inconsistencies
• A single instance of non-compliance that does not indicate a systemic failure
• A procedural step is being skipped occasionally but not consistently
• Documentation exists but contains minor inaccuracies or is slightly out of date

Example: The access control policy requires deprovisioning within 24 hours of termination. Of 15 sampled terminations, 13 were deprovisioned within 24 hours, but 2 were deprovisioned after 48 hours due to holiday coverage gaps.

Significance: In a certification audit, minor nonconformities must be acknowledged with a corrective action plan, but they do not block certification. In an internal audit, they should be addressed within a defined timeframe (typically 30-90 days).

Observations

An observation is a factual finding that is not a nonconformity but warrants attention. Types of observations include:

• Opportunity for improvement (OFI): A conforming area where the organization could enhance effectiveness. Example: “Access reviews are completed as required, but the review process is manual and labor-intensive. Automating the review workflow could improve consistency and reduce the burden on reviewers.”
• Positive observation: A notable strength or best practice. Example: “The organization has implemented just-in-time privileged access with automatic revocation, which exceeds the Annex A requirements and significantly reduces the risk of persistent privileged access.”
• Risk or trend indicator: Something that is currently conforming but trending toward nonconformity. Example: “The last two access reviews were completed in the final week of the review period. If this trend continues, a review may be missed.”

Observations are valuable for continual improvement and should be reported to management alongside nonconformities. They demonstrate that the audit went beyond simple pass/fail checks.

Audit Report Structure

The audit report is the formal documented output of the internal audit. It must be clear, factual, and actionable. Certification auditors will review your internal audit reports as evidence that Clause 9.2 is being met.

Recommended Report Sections

1. Executive summary

A one-page overview for management. Include:

• Audit scope and objectives
• Audit dates and team
• Overall assessment (conforming with observations, minor nonconformities identified, major nonconformity identified)
• Number of findings by classification
• Key themes or systemic issues

2. Audit details

• Audit criteria (standards, policies, and documents audited against)
• Audit methodology (document review, interviews, system observation, sampling approach)
• Departments and personnel involved
• Limitations or exclusions (anything within scope that could not be audited and why)

3. Findings

Each finding should include:

• Finding number (for tracking and reference)
• Classification (major nonconformity, minor nonconformity, observation/OFI)
• Reference (the specific clause, control, or policy requirement that is not being met)
• Description (factual statement of what was found, including evidence references)
• Impact (why this finding matters — what risk does it create or what ISMS objective does it affect)
• Recommended corrective action (the auditor’s suggestion — the auditee decides the actual action)

Example finding:

Finding #3 — Minor Nonconformity

Reference: A.8.2 (Privileged access rights), Access Control Policy v2.1 Section 5.3

Description: The Access Control Policy requires quarterly reviews of all privileged accounts. During the audit period (January-March 2026), one quarterly review was due. The review was completed on March 28, 2026, covering AWS IAM, Azure AD, and Okta administrator accounts. However, the review did not include database administrator accounts in PostgreSQL (RDS) or the CI/CD pipeline service accounts in GitHub Actions. These accounts have production-level access and fall within the policy scope.

Evidence: Access review record dated March 28, 2026 (AR-2026-Q1). Privileged access inventory (PAI-2026-03). Comparison shows 12 privileged accounts in the inventory that were not included in the review.

Impact: Privileged database and CI/CD accounts are not being reviewed per policy, creating a risk of excessive or stale privileged access going undetected.

Recommended action: Expand the access review scope to include all privileged accounts listed in the privileged access inventory. Update the review procedure to include a completeness check against the inventory before the review is closed.

4. Positive observations

Document areas of strength and good practice. This provides balance, recognizes the teams doing things well, and gives management a complete picture.

5. Corrective action tracker

A summary table of all nonconformities with columns for:

• Finding number
• Classification
• Description (brief)
• Assigned owner
• Target resolution date
• Status (open/in progress/closed)

This tracker becomes the working document for corrective action follow-up.

6. Previous audit follow-up

Review the status of findings from the previous internal audit. Verify that corrective actions were implemented and effective. If a previous finding is still open, escalate its classification or flag it as a recurring issue.

Corrective Actions and Follow-Up

Identifying findings is only half the value of an internal audit. The other half is driving corrective actions that actually resolve the underlying issues.

The Corrective Action Process

ISO 27001 Clause 10.1 requires that when a nonconformity occurs, the organization must:

a) React to the nonconformity — take immediate action to control and correct it b) Evaluate the need for action to eliminate the cause — determine root cause and decide whether corrective action is needed c) Implement any action needed d) Review the effectiveness of any corrective action taken e) Make changes to the ISMS if necessary

This is a structured problem-solving process, not just a task list.

Step 1: Immediate correction. Address the immediate symptom. If orphaned accounts were found, disable them now. If a missing access review was identified, conduct the review immediately. This stops the bleeding.

Step 2: Root cause analysis. Determine why the nonconformity occurred. The orphaned accounts exist because the deprovisioning procedure does not include a checklist of all systems, and systems outside the identity provider are missed. The access review was incomplete because the review procedure does not reference the privileged access inventory.

Root cause analysis techniques:

• 5 Whys: Ask “why” repeatedly until you reach the systemic cause. Why were accounts orphaned? Because deprovisioning was incomplete. Why was it incomplete? Because there is no checklist. Why is there no checklist? Because the procedure was written before the current system landscape was established.
• Fishbone/Ishikawa diagram: Categorize possible causes (People, Process, Technology, Policy) and analyze each category.

Step 3: Corrective action plan. Define specific actions that address the root cause, not just the symptom. Assign an owner and a target date for each action.

• Correction (immediate): Disable the 5 orphaned accounts identified — Owner: IT Operations — Due: Within 48 hours
• Corrective action: Update the deprovisioning procedure to include a comprehensive system checklist — Owner: Security Manager — Due: 30 days
• Corrective action: Implement an automated deprovisioning verification check that compares HR termination records against all in-scope system user lists monthly — Owner: IT Operations — Due: 60 days
• Preventive action: Add deprovisioning completeness to the quarterly access review scope — Owner: Security Manager — Due: Next quarterly review

Step 4: Implementation. Execute the corrective actions. Document what was done, when, and by whom.

Step 5: Effectiveness review. After implementation, verify that the corrective action actually resolved the issue. This might mean:

• Re-running the original audit test after the corrective action is implemented
• Monitoring for recurrence over a defined period (typically one cycle)
• Including the finding area in the next audit’s scope with targeted testing

The effectiveness review is the step most organizations skip, and it is the step certification auditors specifically check for. If you identified a nonconformity, implemented a corrective action, but never verified that the action was effective, the auditor will question whether the corrective action process is genuinely operational.

Timeframes for Corrective Actions

Define standard timeframes in your corrective action procedure:

• Major nonconformity: Root cause analysis within 2 weeks, corrective action plan within 30 days, implementation within 60-90 days, effectiveness review within 6 months
• Minor nonconformity: Root cause analysis within 30 days, corrective action implementation within 60 days, effectiveness review within 6 months
• Observations/OFIs: Considered during management review, actioned based on priority and resource availability

Reporting to Management

Clause 9.2.2(d) requires that audit results are reported to relevant management. This feeds into the management review process (Clause 9.3), where management evaluates ISMS performance and makes decisions about resources, priorities, and improvements.

What to report:

• Summary of findings (number and classification)
• Key themes and systemic issues
• Corrective action status (open, in progress, overdue, closed)
• Trends compared to previous audits (improving, stable, declining)
• Resource requirements for corrective actions
• Recommendations for ISMS improvements

How to report: Include audit results as a standing agenda item in your management review. For significant findings, provide an interim briefing to management rather than waiting for the next scheduled review.

Lead Auditor vs. Lead Implementer Certifications

SaaS teams often ask which professional certifications are relevant for ISO 27001 auditing. Understanding the distinction helps you hire the right people and invest in the right training.

ISO 27001 Lead Auditor

What it covers: Audit principles, audit programme management, audit planning and execution, evidence gathering, finding classification, audit reporting, and corrective action follow-up. Based on ISO 19011 (auditing management systems) and ISO 27001.

Who should get it: Anyone who will lead or manage internal audits. External consultants who conduct internal audits on your behalf.

Key competencies: Understanding of audit methodology, objectivity and impartiality, interviewing skills, evidence evaluation, risk-based auditing, report writing.

Certification bodies: IRCA (International Register of Certificated Auditors), PECB, BSI, and others offer accredited Lead Auditor courses (typically 5 days).

ISO 27001 Lead Implementer

What it covers: ISMS design, risk assessment methodology, control implementation, policy development, project management for ISMS implementation, and preparation for certification.

Who should get it: The person responsible for building and maintaining the ISMS. Compliance managers, security managers, or the project lead for ISO 27001 implementation.

Key competencies: Understanding of all ISO 27001 clauses and Annex A controls, risk management methodology, policy and procedure development, project management, change management.

Important distinction: A Lead Implementer should not audit the ISMS they implemented — that violates the independence requirement. However, Lead Implementer knowledge is valuable for audit planning and ensuring the audit team understands the ISMS context.

ISO 27001 Internal Auditor

What it covers: A subset of Lead Auditor content focused specifically on internal audit requirements. Covers audit planning, execution basics, evidence gathering, and reporting, but with less depth on audit programme management and certification audit specifics.

Who should get it: Team members who will participate in internal audits as co-auditors or who will audit specific ISMS areas within their competence.

Duration: Typically 2 days, compared to 5 days for Lead Auditor.

SaaS recommendation: If budget is limited, train one person as a Lead Auditor and 2-3 others as Internal Auditors. The Lead Auditor manages the programme and leads audits. Internal Auditors support by auditing areas outside their own responsibility.

Common Internal Audit Mistakes

Mistake 1: Treating the Audit as a Checkbox Exercise

The problem: The auditor walks through a checklist, confirms that policies exist, and marks everything as conforming without testing whether the policies are actually followed or effective.

The consequence: Real problems go undetected. The certification auditor finds them instead, potentially resulting in nonconformities that could have been prevented.

The fix: For every policy or control, test implementation and effectiveness. Do not just confirm the policy exists — verify that it is being followed. Do not just verify that it is being followed — evaluate whether it is achieving its intended outcome. Ask “show me” instead of “tell me.”

Mistake 2: Insufficient Evidence

The problem: Findings are documented as general observations without specific evidence references. “Access control could be improved” is not a finding — it is an opinion.

The consequence: Corrective actions are unfocused. Management cannot evaluate the severity of the issue. Certification auditors cannot verify that the internal audit was rigorous.

The fix: Every finding must reference specific evidence — document names, record dates, system configurations, interview statements. An effective finding is factual, specific, and verifiable.

Mistake 3: Auditing for Compliance Only, Not Effectiveness

The problem: The audit verifies that processes conform to documented requirements but does not evaluate whether those processes actually achieve their security objectives.

The consequence: An organization can be fully compliant with a set of policies that are inadequate. If the access review process exists and is followed but does not actually detect excessive access, the process is conforming but not effective.

The fix: Include effectiveness questions in your audit checklist. “Is the process followed?” AND “Is the process achieving its intended outcome?” If access reviews are conducted quarterly but never find anything, either the reviews are not thorough enough, or the provisioning process is exceptionally good. Investigate which one it is.

Mistake 4: Lack of Auditor Independence

The problem: The person who built the ISMS audits the ISMS. The security manager who wrote the access control policy audits access control compliance.

The consequence: Unconscious (or conscious) bias. The auditor is less likely to identify weaknesses in their own work. Certification auditors will question the validity of the internal audit.

The fix: Enforce strict independence for each audit area. Use cross-auditing between teams or engage external resources for areas where internal independence is not achievable.

Mistake 5: Not Following Up on Corrective Actions

The problem: Findings are identified and corrective actions are defined, but no one tracks them to completion. The same findings appear in audit after audit.

The consequence: The ISMS does not improve. Recurring findings signal to certification auditors that the corrective action process (Clause 10.1) is not effective.

The fix: Assign clear ownership for every corrective action. Set target dates. Track status in a centralized system. Include corrective action review as a standing agenda item in management meetings. Conduct effectiveness reviews to verify that actions actually resolved the issues.

Mistake 6: Poor Scoping

The problem: The audit scope is too broad (trying to audit everything superficially) or too narrow (missing critical ISMS areas).

The consequence: Broad audits produce shallow findings that lack depth. Narrow audits leave gaps that certification auditors will test.

The fix: Use risk-based scoping to focus audit depth where it matters most. Ensure the full audit programme covers all ISMS areas over the cycle, even if individual audits are focused.

Mistake 7: Not Sharing Results With Management

The problem: The audit report is filed and never discussed. Management is not aware of findings, trends, or resource needs.

The consequence: Clause 9.2.2(d) is not met. Management cannot fulfill their Clause 9.3 management review responsibilities. Corrective actions lack management support and resources.

The fix: Present audit results at every management review. Provide interim briefings for significant findings. Frame findings in terms of risk and business impact, not just compliance gaps.

Frequently Asked Questions

How often must internal audits be conducted?

ISO 27001 requires audits “at planned intervals” — it does not specify a minimum frequency. However, the entire ISMS must be audited at least once per certification cycle (typically annually for surveillance audits, every three years for recertification). Most organizations conduct internal audits annually. Some use a rolling programme with multiple smaller audits throughout the year.

Can we use the same firm for internal audit and certification audit?

No. Using the same firm for both internal auditing and certification would compromise the certification body’s independence. Your certification body cannot provide consulting or internal audit services for the ISMS they certify. You can use a different external firm for internal audits, or conduct internal audits with your own staff.

What happens if the internal audit finds a major nonconformity right before the certification audit?

This is actually a good outcome — better to find it yourself than to have the certification auditor find it. Address the immediate issue (correction), develop a corrective action plan with root cause analysis, and begin implementation before the certification audit. The certification auditor will see that you identified the issue, took action, and are managing it through your corrective action process. This demonstrates ISMS maturity. Hiding or ignoring the finding is far worse.

Do we need to audit every Annex A control every year?

Your audit programme should cover all applicable Annex A controls over the audit cycle, but you do not need to audit every control in a single audit. A risk-based programme allocates more audit time to higher-risk controls and may audit lower-risk controls less frequently (but at least once per cycle). See our ISO 27001 Annex A controls guide for a complete list.

How does the internal audit relate to the SOC 2 audit process?

Internal audits and SOC 2 audits serve different purposes but overlap in practice. The ISO 27001 internal audit is an internal assurance activity that evaluates ISMS conformity and effectiveness. The SOC 2 audit is an external attestation engagement by a CPA firm. If your SaaS company holds both certifications, coordinate the two audit activities to share evidence, reduce duplication, and align corrective action tracking.

What records must we retain from the internal audit?

Retain the audit programme (annual plan), individual audit plans, audit checklists and working papers, evidence collected, the audit report, corrective action records (including root cause analysis, action plans, implementation evidence, and effectiveness reviews), and management review minutes where audit results were discussed. Retain these records for at least the current and previous certification cycle (typically 3-6 years). Your certification checklist should include a reminder to verify audit record retention.

How GRCTrail Helps

GRCTrail streamlines ISO 27001 internal audit planning, execution, and follow-up for SaaS teams:

• Audit programme management with pre-built audit templates mapped to every ISO 27001 clause and Annex A control, automated scheduling, and risk-based prioritization that allocates audit effort where it matters most
• Evidence collection integration that pulls audit evidence directly from your connected systems (cloud platforms, identity providers, code repositories), eliminating manual screenshot collection and accelerating evidence gathering
• Corrective action tracking with assigned ownership, target dates, automated reminders, and effectiveness review workflows that ensure findings are resolved rather than forgotten

Get started with GRCTrail

Related Guides

• What Is ISO 27001? A Practical Guide for SaaS Companies
• ISO 27001 Requirements: Understanding Clauses 4-10
• ISO 27001 Continuous Improvement: Building a Self-Improving ISMS
• ISO 27001 Certification Checklist
• ISO 27001 Statement of Applicability: A Complete Guide
• The SOC 2 Audit Process: Timeline, Steps, and What to Expect