An ISO 27001 readiness assessment should answer a commercial question: what must this organisation do, with which people and systems, before an independent certification body can audit it? A spreadsheet of “yes”, “no” and “partial” answers is not enough. A useful assessment connects the standard to your proposed scope, actual risks, operating controls, evidence and available team capacity.
This is a focused spoke in the ISO 27001 for startups roadmap. It is written for founders and security or operations leads deciding whether to implement, how much to budget and whether a promised timeline is credible.
Important distinction: a readiness assessment is an advisory view of current conformance. It is not an ISO certificate, and a consultant who implements controls should not present its own implementation review as fully independent internal audit evidence.
Before reviewing controls, agree the business outcome and the certification boundary. Are you responding to a customer requirement for one SaaS product, preparing a group-wide programme, or building a foundation for SOC 2 and ISO 42001 as well? The answer changes the scope, evidence and priority order.
The assessor should document the proposed ISMS scope in plain language: products and services, locations, legal entities, people, technology environments, information types and important interfaces. It should identify dependencies that materially affect the scoped service, including cloud platforms, identity, source control, customer support, outsourced development and critical suppliers. A narrow scope is acceptable; an implausibly narrow scope is a risk.
Next, establish the organisation's context and interested parties. Customer contracts, procurement questionnaires, regulators, employees, founders, investors and suppliers can each create requirements. The assessment should flag where an ISO decision intersects with GDPR, the EU AI Act, sector obligations or customer-specific terms rather than pretending ISO 27001 resolves those obligations.
Policies, risk records, access exports, change records, incident tickets, supplier reviews, backup tests and training reports show what the organisation says and does. The assessor should sample actual records, not only accept a document index. For a cloud startup, that may mean tracing one production change from ticket to pull request to deployment, and one leaver from HR notification to access removal across relevant systems.
Conversations reveal whether responsibilities are real. Ask the engineer who approves a production change, the person who reviews suppliers and the founder who accepts residual risk. Can they explain the trigger, frequency, exception path and evidence location? If every answer is “the consultant handles that”, the organisation is not ready to own its ISMS.
ISO 27001 is risk-driven. A finding should explain which risk or requirement is relevant, which clause or control is implicated, what is currently in place, and what outcome is needed. The assessor should distinguish a missing policy from a control that exists but has not operated, and from a control that operates but is not consistently evidenced. Those are different work items with different time and cost.
The review should cover scope and context, leadership and policy, risk assessment and treatment methodology, Statement of Applicability, objectives, competence and awareness, documented information, operational planning, performance evaluation, internal audit, management review and corrective action. Annex A is important, but checking 93 controls while ignoring the management-system clauses produces a misleading readiness score.
Expect a written report that another leader can use to make decisions, not merely a colour-coded workbook. At minimum it should contain:
Severity labels are only useful when defined. A “high” finding might be an absent risk method, an unowned production access process or a scope boundary that omits a critical dependency. A minor formatting issue should not compete for attention with a control that has never operated. Ask how priorities were determined and what must be closed before Stage 1 versus what can be handled during continual improvement.
Convert each finding into a work package. For example, “access control partial” is not a budget line. Break it into identity inventory, privileged-account design, joiner-mover-leaver workflow, access review cadence, technical configuration and evidence samples. Name the internal owner, external help required, dependency and acceptance test. This makes a fixed-fee proposal comparable with a time-and-materials proposal.
Keep separate budgets for consultancy, internal time, technical remediation, software, penetration testing where justified, certification-body audits and ongoing surveillance support. Certification-body fees are not the same as implementation fees and should be obtained directly or clearly identified as an estimate. Our guide to comparing consultancy scope and cost explains the questions to ask.
Do not use the assessment to promise a certificate date before checking the operating period. Policies can be approved quickly; access reviews, backup restoration tests, supplier reviews and management monitoring need real cycles. The implementation timeline guide shows how evidence time affects scheduling.
Sequence decisions that unblock other work. Confirm scope and risk methodology before writing a large policy library. Establish owners before collecting evidence. Fix identity and change-management weaknesses before claiming technical controls are effective. Run the internal audit and management review only when the ISMS has enough operating history to review meaningfully.
A startup with a clear product boundary and mature cloud practices may need four to six months; a business with multiple locations, legacy infrastructure, acquisitions or limited owner time may need nine months or more. The assessment should show which assumption drives the range instead of hiding uncertainty behind a generic “12-week” plan.
A provider should answer these directly. Be cautious of an assessment that guarantees certification, treats every Annex A control as universally mandatory, promises an audit before evidence exists, or sells a platform score without speaking to control owners.
Agree the acceptance criteria for each priority finding, assign owners and review progress at a regular governance meeting. Keep the original assessment as a baseline; do not silently rewrite it as gaps close. Update risk decisions when scope, suppliers or product architecture change. Before Stage 1, perform a readiness check against the actual certification-body plan. Before Stage 2, complete internal audit, management review and corrective action with objective evidence.
Read how to follow one control from risk to evidence as a practical test of whether the roadmap is creating an operating ISMS rather than a document collection.
We can review your proposed scope, buyer requirement and current evidence, then identify the work needed before certification.
Discuss an ISO 27001 assessment →