Your first ISO 27001 audit is a milestone—one that tells customers, partners, and regulators that you take information security seriously. But auditors don’t expect perfection; they expect evidence that you’ve identified risks and are managing them deliberately.

The gap most organizations face isn’t a lack of security controls. It’s lack of documentation that those controls exist and are working. Before your audit starts, close these 10 risks that auditors will look for.

1. No Documented Risk Assessment

ISO 27001 clause 12.6.1 requires a documented information security risk assessment. Many organizations skip this or do it casually in a spreadsheet.

What auditors see: A company with no formal risk register, no dates, no evidence of review.

What to do:

  • Conduct a baseline risk assessment across all information assets (data, systems, people).
  • Document each identified risk with likelihood, impact, and current mitigation.
  • Have leadership sign off on the results.
  • Keep it updated—auditors want evidence of ongoing assessment, not a one-time event.

Tools that handle this well let you document risk in one place and tie it to controls, so you’re not maintaining separate lists.

2. Missing or Outdated Policies

Clause 5.1 requires an information security policy. Most organizations write one and forget it.

What auditors see: A policy from 2019 that doesn’t mention remote work, cloud services, or your actual security team structure.

What to do:

  • Write policies covering: access control, password management, incident response, vendor management, and data classification.
  • Review and update them annually (or when your business changes).
  • Have your executive team approve and sign off in writing.
  • Distribute to staff and keep records of who read them.

Don’t overthink this. Policies don’t need to be 50 pages. Clear, concise, and actual is far better than lengthy and ignored.

3. No Evidence of Access Reviews

Clause 6.2 requires that access is reviewed periodically. This trips up many growing teams.

What auditors see: User accounts that haven’t been touched in two years, former contractors still in systems, no approval trail.

What to do:

  • Run an access audit across critical systems (email, cloud apps, databases, networks).
  • For each user, verify their role and confirm the access is still needed.
  • Document who reviewed what, when, and who approved it.
  • Do this at least annually; more often for high-risk systems.
  • Remove stale or unauthorized accounts.

This is painful the first time but becomes routine after.

4. Incident Response Plan Not Tested

Clause 16.1 requires an incident response and management procedure. Having a plan and testing it are different things.

What auditors see: A response plan document with no evidence anyone has practiced it.

What to do:

  • Document your incident response process: detection, containment, eradication, recovery, notification.
  • Assign clear roles (incident owner, technical lead, communications lead).
  • Run a tabletop exercise or simulation at least once a year.
  • Document what happened and what you learned.
  • Update your plan based on what you discover.

Auditors want to see that if something goes wrong, you know what to do.

5. Vendor Risks Not Tracked

Clause 15.1 requires management of information security risks related to supplier relationships. Auditors increasingly scrutinize this.

What auditors see: A long list of cloud vendors, integrations, and contractors with no risk assessment or ongoing monitoring.

What to do:

  • List all vendors that access, process, or store your data.
  • Assess each one: What data do they touch? What happens if they fail? What’s their security posture?
  • Document your vendor contracts and ensure they include security and audit requirements.
  • Review vendor security regularly (ask for attestations, SOC 2 reports, or security questionnaires).
  • Have a plan for vendor offboarding.

You don’t need to audit every vendor yourself—but you need to show you’ve thought about the risk.

6. No Documented Security Awareness Training

Clause 6.3 requires awareness training for all personnel. Most companies do training but don’t keep records.

What auditors see: No list of who took training, when, or what they learned. Or a single annual session with no follow-up.

What to do:

  • Establish annual security training (phishing, password safety, data handling, incident reporting).
  • Track attendance, completion dates, and what was covered.
  • For high-risk roles (developers, support staff, finance), provide role-specific training.
  • Conduct phishing simulations and measure results.
  • Keep records for at least 3 years.

Training doesn’t need to be formal classroom sessions. Short videos, quizzes, or even emails count—as long as you can prove people engaged.

7. Cryptography Use Not Documented

Clause 10.1 restricts use of cryptography. Auditors check for encryption of sensitive data and proper key management.

What auditors see: Sensitive data in plain text, “encrypted” with unclear methods, or encryption keys stored in code.

What to do:

  • Document which data requires encryption (payment cards, personal information, trade secrets).
  • Map where each data type is encrypted: in transit (TLS), at rest (AES-256), or in backups.
  • Document your key management process: who creates, rotates, and stores encryption keys.
  • For cloud services, confirm the provider handles encryption and key management for you—and keep their documentation.
  • Test decryption works (too many organizations encrypt and can’t recover).

8. Change Management Process Not Followed

Clause 12.1.1 requires a change control procedure for information systems. Untracked changes are a common audit finding.

What auditors see: System changes deployed without approval, no record of who made changes or when, configuration drift.

What to do:

  • Document your change management process: request, review, approval, testing, deployment, rollback plan.
  • Require written approval before changes go live.
  • Log all changes with who made them, when, and why.
  • For critical systems, enforce testing or a change window.
  • Review change logs monthly and flag unauthorized changes.

This doesn’t require complex tools—a change log in a shared spreadsheet with approvals is fine if it’s actually used.

9. No Backup Testing or Disaster Recovery Plan

Clause 12.3.1 requires backup policies. Backups sound simple but many organizations discover during an audit (or a breach) that they don’t work.

What auditors see: Backups configured but never verified, no recovery time objective (RTO) or recovery point objective (RPO) defined, no evidence of a restore test.

What to do:

  • Define RTO (how fast you need to recover) and RPO (how much data loss is acceptable) for critical systems.
  • Ensure backups cover all critical data: databases, file servers, cloud applications.
  • Test restores quarterly—not just backup completion, but actual recovery.
  • Document the results.
  • Have a documented disaster recovery plan with roles and runbooks.

One full restore test before your audit will answer most auditor questions.

10. No Monitoring or Log Review Process

Clause 12.4.1 requires logging and monitoring. Auditors want evidence you’re detecting problems.

What auditors see: Logs collected but never reviewed, security alerts ignored, no clear process for investigating anomalies.

What to do:

  • Enable logging on critical systems: authentication, privileged access, data modifications, security tool alerts.
  • Define a process to review logs or alerts regularly (weekly or monthly depending on risk).
  • Document what you looked for, when, and what you found.
  • For any security event (failed logins, unauthorized access attempts), show evidence of investigation.
  • Archive logs for at least 12 months.

You don’t need a 24/7 security operations center. A scheduled weekly review of logs and alerts is enough for most small to mid-sized organizations.

The Preparation Timeline

If your audit is 3+ months away:

  • Month 1: Conduct risk assessment, review and update policies, document incident response plan.
  • Month 2: Run access review, assess vendors, test backups, audit change logs.
  • Month 3: Verify all training is documented, test logging and monitoring, ensure all evidence is organized.

If you’re closer to the audit date, prioritize risks 1–5 first (risk assessment, policies, access reviews, incident response, vendor management) and work through the rest.

Organize Your Evidence

Auditors will want to see proof for each of these 10 areas. Rather than scrambling to find emails and documents, consolidate everything:

  • Keep policies and approvals in one place.
  • Store risk assessments with review dates.
  • Document access reviews with clear before/after lists.
  • Maintain a change log with approval chains.
  • Archive incident response drills and outcomes.
  • Collect training records, vendor assessments, backup test reports.

Many organizations use a centralized system (sometimes a shared folder, sometimes a dedicated GRC platform) to pull all this together. Whatever you choose, make it easy to find and export evidence during the audit.

Ready for the Audit

Your auditor isn’t looking for a perfect security program—they’re verifying that you’ve thought about risks and put practical controls in place. Address these 10 areas, document what you’ve done, and you’ll walk into that first ISO 27001 audit with confidence.