Plenty of companies assume that building out their Information Security Management System is the hard part of ISO 27001, and that getting certified is just paperwork. The surprise shows up at the audit. The certification body isn’t grading your good intentions or how well your policies are written—it’s checking whether you can prove, with real evidence, that your ISMS works exactly the way the documentation says it does.

In this article, we’ll walk you through how the ISO 27001 certification process works from start to finish—from the prerequisites to how you keep the certificate once you’ve earned it.

What does ISO 27001 certification actually mean?

Being ISO 27001 certified means an accredited certification body has audited your Information Security Management System (ISMS) and confirmed that it meets the requirements of the standard. Implementing the standard and getting certified aren’t the same thing. Implementation is the internal work—designing policies, assessing risks, and applying controls. Certification is the external recognition that validates that work.

The certificate is issued by an independent body, never by ISO itself, and it’s valid for three years, subject to annual surveillance audits. Without that stamp, no matter how solid your ISMS is, you can’t prove to customers, partners, or government agencies that you meet the standard.

Prerequisites

Before you reach out to a certification body, your organization needs to meet a handful of minimum conditions. Requesting the audit without them usually translates into nonconformities that slow the whole process down.

An ISMS that’s implemented and running: having your policies written isn’t enough—the system has to be live, with evidence that it’s actually followed day to day.
Statement of Applicability (SoA) and Risk Treatment Plan: these are the first documents the auditor reviews. They need to spell out which Annex A controls you apply and why.
A prior internal audit: the standard requires you to have reviewed your own ISMS before an external auditor does.
Management review: top management needs to have formally evaluated the ISMS’s performance and documented it.
A minimum evidence trail: most certification bodies recommend at least three months of records (access, incidents, training) so they can audit the system in real operation and not just on paper.

How to choose a certification body

Not every company can issue a valid ISO 27001 certificate. The certification body has to be accredited by a national accreditation body—in the US, that’s the ANAB (ANSI National Accreditation Board)—or its equivalent in other countries under the IAF mutual recognition framework. A certificate from an unaccredited body carries no weight with customers or agencies.

Beyond accreditation, it’s worth comparing a few criteria before you sign with a body.

Experience in your industry: an auditor who knows the typical risks in your field will interpret your scope and your controls better.
International recognition: if you work with customers outside the US, check that the certificate is recognized in those markets.
Transparency on cost: ask for a breakdown of the audit phases, not just a flat price, so you’re not caught off guard during the annual surveillance.
Scheduling availability: the most in-demand bodies can take weeks to assign an auditor—something to plan for if you’re working against a commercial deadline.
Independence: the auditor can’t have been involved in consulting on or implementing your ISMS. The standard requires a separation between whoever helps you implement and whoever certifies you.
Verifiable references: ask to talk to companies in your industry that this body has already certified. The real experience of other customers tells you more than a sales sheet.

The phases of the certification audit

The ISO 27001 certification audit isn’t a single exam—it’s a two-stage process that first evaluates how your ISMS is designed, then how it actually runs. Understanding what the auditor looks at in each stage helps you show up prepared and avoid confusing ‘the documentation is ready’ with ‘we’re ready for Stage 2.’

Stage 1 audit: the documentation review

In this first stage, the auditor reviews your ISMS documentation without yet evaluating how it’s applied day to day. The goal is to confirm the system is designed in line with the standard before moving on to the operational part.

The documents that get the most scrutiny here are the Statement of Applicability, the Risk Treatment Plan, the information security policy, and the scope defined for the ISMS. For example, if your Statement of Applicability says you apply control A.8.10 on secure information deletion, the auditor will look for the documented procedure describing how that control is carried out—even if they don’t yet verify whether it’s followed in practice.

If Stage 1 turns up significant gaps, like a poorly defined scope or documents that don’t reflect the organization’s real controls, the auditor can ask you to fix them before setting a date for Stage 2. Getting ahead of this review with your own internal audit lowers the risk of surprises at this point.

Stage 2 audit: the on-site audit

This is where they evaluate whether what the documentation says holds up in practice. The auditor interviews people from different areas, not just the IT team or the security lead, and reviews access, incident, and training records to check the theory against the actual operation.

Offboarding is a common example. If your policy says access is revoked the same day an employee leaves the company, the auditor might ask for the record of a recent departure and check the exact date and time the accounts were deactivated. Device management is another classic. The auditor may request the inventory of company devices to verify it matches the machines physically present, or ask a random employee how they handle encryption on their laptop.

This stage usually relies on sampling—the auditor doesn’t check 100% of cases, but a representative selection. That’s why consistency matters more than one well-handled case. If a process only works when someone preps it specifically for the audit, the sample tends to expose it.

Handling nonconformities

If the auditor finds gaps between what’s documented and what’s actually applied, they classify them by severity.

Minor nonconformity: a one-off or isolated issue, like an incomplete training record for one employee. It’s usually resolved with an action plan within a few weeks, without redoing the audit.
Major nonconformity: a systematic issue, or one that undermines the effectiveness of the ISMS—like a key Annex A control that isn’t applied at all, or a total absence of evidence for a required process. This kind of finding can force an additional visit from the auditor before the certificate is issued.
Opportunity for improvement: not a nonconformity, but a recommendation the auditor flags to strengthen the system in future cycles.

Issuing the certificate

Once the nonconformities are closed out, the certification body issues the ISO 27001 certificate with a three-year validity. That validity is tied to annual surveillance audits, which check whether the ISMS is still active and whether previous nonconformities have been effectively resolved.

The certificate usually spells out the exact scope that was audited, so it’s worth reviewing carefully before you share it with customers or include it in a bid—a poorly worded scope can raise awkward questions during a procurement process.

How long does it take?

There’s no standard timeline. A small organization with a tight scope and already-digitized processes can complete the whole thing—from the initial assessment to the certificate being issued—in a few months. Larger organizations, with multiple sites or legacy systems, can need anywhere from six months to more than a year.

The factors that weigh most on the timeline are your existing maturity in information security, the size of the scope defined for the ISMS, whether evidence is already centralized versus something you have to reconstruct by hand, and the schedule of the certification body you choose. The most common piece of advice from people who’ve already been through it is to treat it as a project with dedicated resources from the start, not as one more task tacked onto the IT team’s day job.

How do you keep the certification?

Getting the certificate often feels like the finish line, but it’s really the starting point of a three-year cycle. The certification body doesn’t disappear after handing you the stamp—it comes back at regular intervals to check that your ISMS is still alive and hasn’t frozen in the state it was audited in.

Annual surveillance audits: shorter visits than the initial certification, usually focused on a sample of controls rather than the whole system. The auditor checks that the nonconformities found during certification have actually been fixed and not just on paper, and tends to rotate which areas it reviews from year to year so it isn’t auditing the same things every time.
The recertification audit: this happens before the three-year validity expires, and its scope is closer to the original Stage 2. If the ISMS stayed active through the annual surveillances, this audit is more of a confirmation than a surprise. If unresolved patches have been piling up, this is when they all come to light.
Continual improvement of the ISMS: the standard doesn’t let you leave the system exactly as it was certified. Every security incident, every new tool you bring in, every change in the organization should translate into a review of risks and controls. An ISMS that doesn’t get updated is one of the most common causes of nonconformity in surveillance audits.
Continuity in your evidence: keeping the certification depends on being able to show, at any moment and not just before a visit, that the controls are still working. Access, incident, and training records need to be generated continuously, to avoid the same last-minute scramble that already complicates the initial certification.

The most common mistakes

Most certification processes don’t fail for lack of technical know-how. They fail because of management decisions that seem minor at the time and later cost weeks of delay. These are the mistakes that come up most often.

Treating certification as a one-time box to check: when the goal is just to get the stamp, the ISMS gets documented to pass the audit, not to run day to day. The result is a system that scrapes through Stage 2 and starts racking up nonconformities at the very first annual surveillance.
Leaving evidence for the end: access, incident, and training records can’t be reconstructed from memory two weeks before the audit. If they aren’t generated continuously, gaps appear that the auditor spots right away—and they’re much harder to justify than a control that’s simply applied badly.
Underestimating the time and resources: getting certified isn’t a task you can absorb between the IT team’s other responsibilities. Without dedicated time and explicit backing from leadership, the project drags on, loses priority against the day-to-day urgencies, and shows up to the audit less prepared than planned.
Choosing a certification body on price alone: a lower rate that doesn’t include industry experience or good scheduling availability usually turns out expensive another way—in timelines that stretch out or an audit that’s more of a burden to manage internally.
Repeating the same nonconformity at every audit: a one-off finding doesn’t put the certification at risk, but a gap that reappears audit after audit does—because it signals the control was never actually fixed, just patched up for the next visit.
Not involving people outside IT: Stage 2 includes interviews with employees across different areas, not just the technical team. If no one else in the organization knows the ISMS policies, that gap between what’s documented and what people actually know tends to surface at exactly that moment.

How does Factorial IT help?

The most time-consuming part of the process usually isn’t designing the policies—it’s proving they’re being followed. Factorial IT centralizes device, access, and security management across your organization, and turns that management into audit-ready evidence.

Real-time asset inventory. The MDM keeps an up-to-date record of every company device—one of the first things any auditor reviews in Stage 1.
Centralized SaaS access management. Every provisioning, deprovisioning, and permission change is logged, which makes it easier to justify access control during Stage 2.
Automated, documented offboarding. When an employee leaves, their access is revoked and their device is locked automatically, with a date and time stamp—a control auditors check often.
Endpoint detection and response (EDR). Provides evidence that devices are protected and monitored, not just inventoried.
Logs you can export anytime. Instead of reconstructing evidence by hand before every audit, activity, access, and incident records stay available continuously, which cuts down the prep work for both the initial certification and the annual surveillances.

With this foundation, your team walks into the audit with real, verifiable evidence—instead of scrambling to pull it together in the weeks before the auditor shows up.

How to Get ISO 27001 Certified: A Step-by-Step Guide