A realistic ISO 27001 plan has two clocks. The first is delivery: define the scope, build the ISMS, implement controls and complete readiness activities. The second is operation: controls must run long enough to produce credible evidence before an independent auditor tests them. A startup can move quickly through the first clock and still be unready for Stage 2.
This timeline is a practical planning model within the ISO 27001 guide hub, not a promise of a universal certificate date. A focused 10–50 person SaaS company with good cloud practices may take four to six months. Multiple products, locations, legacy systems, weak ownership or limited internal availability can extend the route to nine months or more.
Book the certification body early, but do not book Stage 2 before the system can demonstrate operation. Stage 1 and Stage 2 dates, auditor availability, findings and required evidence all affect the final plan.
Confirm the buyer outcome, scope, interested parties, owners, project cadence and certification-body requirements.
Establish the risk method, asset and supplier picture, treatment plan, objectives and Statement of Applicability.
Tailor policies, fix priority technical gaps, train owners and begin collecting real evidence.
Complete internal audit, management review, corrective action and a structured evidence review.
Respond to documentation findings, host the certification audits and close nonconformities objectively.
Start with why certification is needed and which customer or procurement event drives the date. Collect the exact wording: an accredited ISO 27001 certificate, a defined service scope, a current SOC 2 Type 2 report or another form of assurance are different deliverables. Identify the legal entity, products and locations that must appear in the claim.
Map the service boundary and dependencies. Include production and development environments, identity, endpoints, support, source control, people, key suppliers and information flows that can affect the scoped service. Agree who approves risk, who coordinates the ISMS and who owns each important control. If the startup is considering a narrow scope, the startup scope guide gives practical tests for whether it is defensible.
Contact candidate certification bodies in this period. Confirm accreditation, audit availability, scope wording, audit duration assumptions and how they treat Stage 1 findings. Certification-body fees are separate from implementation support; include both in your plan.
Run a readiness assessment and use its findings to set the baseline. Establish a repeatable risk method: identify assets and threats, assess likelihood and impact, choose treatment, assign an owner and record acceptance or transfer decisions. Create the risk treatment plan and draft the Statement of Applicability from those decisions rather than ticking every control by habit.
Define information-security objectives and how management will measure them. Tailor policies to actual tools and responsibilities. Set rules for document control, exceptions, changes, incidents, suppliers and corrective action. The goal is not to complete a library in week five; it is to create an ISMS people can operate and improve.
A proper readiness assessment should separate missing documentation, technical remediation and missing operating history. That distinction makes the timeline and budget more honest.
Implement the controls that address the highest risks first. For most software startups this includes identity and privileged access, joiner-mover-leaver, secure development and change, vulnerability management, backup recovery, incident response, supplier oversight and security awareness. Build evidence into existing workflows: tickets, pull requests, identity logs, training records, review notes and test reports.
Run a recovery test and incident exercise rather than merely approving plans. Perform at least one access review, supplier review and vulnerability-remediation cycle where the cadence requires it. Record exceptions and corrective actions. Evidence of a failure followed by a documented response is often more credible than an artificially clean register.
Owners need time to learn their responsibilities. Have each person explain the trigger, action, evidence location and escalation route. Keep a weekly action register with owner, due date, dependency and acceptance criterion. If all tasks sit with a consultant, build a handover plan immediately.
Do not compress internal audit into a document proofread. The internal auditor should evaluate the ISMS against clauses 4–10, the Statement of Applicability and applicable controls, using interviews and samples. Findings should identify the requirement, condition, impact and corrective action. If the implementation consultant also built the system, use an independent reviewer or disclose the limitation and arrange an appropriate independent check.
Management review should examine objectives, audit results, incidents, interested-party changes, performance metrics, risks, resources and improvement actions. It is a decision meeting, not a signature exercise. Record what leadership approved, changed or funded. Close material corrective actions and retain objective evidence of completion.
The practical evidence question is whether you can follow one risk to its treatment, control owner, operating record, review and corrective action. The evidence-before-audit guide walks through that chain.
Stage 1 assesses whether the ISMS is designed and sufficiently implemented to proceed to Stage 2. The auditor reviews scope, context, policy, risk method, Statement of Applicability, objectives, internal audit and management review arrangements, among other elements. Stage 1 is not a guarantee that Stage 2 will pass and is not a substitute for running controls.
Allow time after Stage 1 to understand and address findings. Clarify which findings must be closed, which can be verified at Stage 2 and what evidence the auditor expects. A rushed Stage 2 booking can turn a manageable observation into a preventable nonconformity.
Stage 2 tests whether the ISMS and selected controls conform and operate in practice. Expect interviews, record sampling, system walkthroughs and questions about exceptions. Control owners do not need to recite clause numbers; they do need to explain what they do and show reliable evidence.
If the auditor raises nonconformities, agree the root cause, correction, corrective action and objective evidence for closure. Certification is issued by the certification body after its process accepts the response; a consultant cannot guarantee the outcome. Once certified, plan surveillance audits, ongoing risk review, management review and continual improvement.
Use dates as checkpoints, not as evidence that work is complete. For each phase, record the decision that must be made, the owner, dependency, evidence required and consequence of delay. Add buffer for certification-body scheduling and findings. Budget internal time alongside consultancy, technical remediation, tooling and audit fees; the scope and cost guide can help compare proposals.
For implementation support tailored to your service and buyers, see ISO 27001 implementation for startups.
Bring your target date, scope and current controls. We will identify the operating evidence and decisions that stand between kickoff and audit.
Discuss your implementation plan →