Compliance software collects the evidence. A consultant builds the system that evidence is meant to prove. That’s the real difference in the ISO 27001 consultant vs software decision, and most teams only figure it out after they’ve bought one and realized they still need the other. Below, we compare what each route covers, where it breaks down, and what it costs you in time, money, and your team’s hours. Short version: software on its own works for a small group of companies. For most SaaS and tech scale-ups trying to get an enterprise deal over the line, consultant-led implementation on a compliance platform is the faster and safer path to a certificate. Quick Answer: Consultant, Software, or Both? Software-only works if you already have an in-house security lead who’s taken a company through ISO/IEC 27001 before and has the time to own the project. Consultant-only still makes sense if you run mostly on-premise or legacy systems that platforms barely integrate with. For everyone else, which means most cloud-native companies under a few hundred people, a hybrid works best: a platform to handle evidence and monitoring, and a consultant to build the management system and stand behind it in front of an auditor. Here’s why. What an ISO 27001 Consultant Handles ISO/IEC 27001:2022 is a management system standard. Clauses 4 to 10 cover how you run information security, and Annex A lists 93 controls you pick from based on risk. Almost none of it is box-ticking. Most of it comes down to judgment calls about your business, and that’s what you’re paying a consultant for. Scoping, Gap Analysis and Risk Assessment Scope is the first decision you make, and the most expensive one to get wrong. Go too wide and you’ll spend months on controls for systems no customer asks about. Go too narrow and the certificate won’t get through the procurement review it was supposed to pass. A consultant scopes around the deals you’re trying to close, runs a gap analysis, and builds a risk assessment based on your real assets and threats. That’s the document auditors dig into hardest. ISMS Documentation and Policy Writing The standard asks for a specific set of documents: the ISMS scope, information security policy, risk assessment and treatment methodology, Statement of Applicability, risk treatment plan, and evidence of competence, monitoring, internal audit, and management review. A consultant writes these around how your company works day to day, instead of how a template imagines it works. Auditors check whether you follow your own procedures, so a mismatch shows up fast. Internal Audit and Certification Audit Support You need an internal audit before certification, and Clause 9.2 says the auditor has to be objective and impartial. In a small company, the people who built the ISMS can’t credibly audit it, so most teams outsource it through ISO 27001 internal audit services. A good consultant also gets your team ready for the Stage 1 and Stage 2 audits, joins the conversations that matter, and handles corrective actions if the auditor raises nonconformities. What ISO 27001 Compliance Software Handles Compliance automation platforms, often called GRC platforms, have changed how cloud-native companies get certified. They’re very good at the repetitive, evidence-heavy side of the work. Automated Evidence Collection and Continuous Control Monitoring The platform plugs into your cloud provider, identity provider, code repos, HR system, and device management tools, then pulls evidence on its own. It’ll flag an unencrypted storage bucket, an ex-employee who still has access, or a laptop without disk encryption. For technical controls, that saves weeks of screenshots and spreadsheet tracking. Policy Templates and Annex A Control Mapping Most platforms come with a policy library and map each control to the ISO 27001 clauses and Annex A. You get a starting point and a clear view of which controls have evidence and which don’t. Auditor Access and Ongoing Compliance Tracking Auditors can log in and review evidence themselves, which cuts down fieldwork. After you’re certified, dashboards show when controls slip between surveillance audits, so you aren’t rebuilding evidence from scratch every year. Where Each Approach Falls Short Neither route covers everything by itself. The good news is that the ways each one fails are predictable, so you can plan around them. Limits of Compliance Automation Platforms A platform can tell you a control is failing. It can’t decide your scope, run your risk assessment, write a policy that matches your operations, convince your CTO to change the offboarding process, or explain to an auditor why you excluded a control from your Statement of Applicability. Templates can also make you feel further along than you are. A dashboard at 90% can hide an ISMS that won’t survive Stage 1, because the missing 10% is the management system itself. Insider Note: The Stage 1 problem we see most on software-only projects is a risk assessment copied straight from the platform’s default risk library. The risks are generic, the scores are almost identical, and nothing ties back to the company’s own assets. Auditors notice within minutes, and it weakens the Statement of Applicability that’s built on it. The other problem is ownership. Software assumes someone inside the company will drive the project. At most startups that’s a CTO or ops lead who already has a full-time job, and the subscription renews whether the work gets done or not. Limits of a Consultant-Only Approach A consultant working without automation spends billable days on things a platform does for free, like chasing screenshots, updating evidence trackers, and collecting the same proof again before every surveillance audit. You pay more and wait longer. You also end up with a program that’s only accurate on the day it’s handed over. Once the engagement ends, the evidence goes stale and year-two surveillance turns into a scramble. ISO 27001 Consultant vs Software: Side-by-Side Comparison Factor Consultant only Software only Hybrid (consultant + platform) Time to audit readiness 3 to 6+ months Highly variable; depends on internal expertise As little as 6 weeks for well-scoped
Most people asking this question fall into one of two camps. Either they already hold ISO 27001 and just shipped an AI feature, or they run an AI-native company and an enterprise buyer has asked for “your AI governance certification.” The answer is the same for both camps: ISO 27001 secures your information and ISO 42001 governs your AI. Neither certificate covers the other. If AI is part of what you sell or how you make decisions, you’ll need both. If it’s just a productivity tool humming away in the background, ISO 27001 on its own is still fine. Below: what each standard governs, where they overlap, what your existing ISMS doesn’t say about AI, how to decide, and how to run both as one management system rather than two. The Short Answer: When You Need Both (and When You Don’t) You need both when AI is part of your product or part of a decision that affects people, and a customer, regulator, or board could reasonably ask how you govern it. That covers most SaaS companies with a generative feature, every AI-native vendor, and any firm using AI to screen candidates, score credit, or make health or safety calls. ISO 27001 alone is enough when your AI use is internal and low-stakes. Coding assistants, drafting tools, a chatbot answering FAQs from public docs. Your ISMS already covers the data those tools see, and nobody is asking you for an AI management system. ISO 42001 on its own is a rare choice, and usually a bad one. The standard assumes there’s a working security baseline underneath it. An AI governance certificate sitting on top of an unaudited security program raises more questions than it answers, so ISO 27001 comes first or at the same time. What ISO 27001 Covers vs What ISO 42001 Covers ISO 27001: Information Security Management System (ISMS) ISO/IEC 27001:2022 sets out the requirements for an Information Security Management System. The thing being protected is information. The risk being managed is losing its confidentiality, integrity, or availability. Annex A lists 93 controls across organizational, people, physical, and technological themes, and you explain which ones apply in a Statement of Applicability. The certificate tells customers you protect the data they systematically hand you. ISO 42001: AI Management System (AIMS) ISO/IEC 42001:2023 sets out the requirements for an Artificial Intelligence Management System. It’s the first certifiable standard for how an organization develops, provides, or uses AI. The thing being governed is the AI system across its whole lifecycle, and the risks go well past security: harm to people, bias, opacity, and a lack of human oversight. Annex A lists 38 controls under nine objectives, covering AI policy, impact assessment, lifecycle management, data governance, and third-party relationships. The certificate tells customers you can explain what your AI does, who’s accountable for it, and how you stop it from doing damage. ISO 42001 vs ISO 27001: The Key Differences ISO 27001:2022 ISO 42001:2023 What it governs Information assets and the systems that process them AI systems across their lifecycle, whether built, bought, or used Core risk question Can this data be stolen, altered, or made unavailable? Can this AI system harm people, mislead them, or operate without accountability? Annex A controls 93 security controls in 4 themes 38 AI controls across 9 objectives Key assessment Information security risk assessment AI risk assessment plus AI system impact assessment Typical requester Every enterprise security review AI-focused questionnaires, regulated buyers, boards, EU AI Act mapping Maturity Established since 2005, revised 2022 First edition, December 2023; auditors accredited under ISO/IEC 42006 Scope: Information Assets vs AI Systems ISO 27001 draws its boundary around information and the infrastructure that handles it. ISO 42001 draws its boundary around AI systems and their use cases: a recommendation engine, a customer-facing agent, a hiring model, a third-party LLM embedded in your product. The same company can hold both certificates with different scopes. On a first certification cycle the AI scope is usually the narrower one. Risks Managed: Security Risk vs AI Impact and Ethical Risk An ISMS asks what happens if an attacker gets in. An AIMS also asks what happens when the system works exactly as designed and still produces a biased shortlist, a made-up policy answer, or a decision nobody can explain to the person it affected. Clause 6.1.4 of ISO 42001 requires an AI system impact assessment that looks at consequences for individuals and society. ISO 27001 has nothing like it. Controls: Annex A Security Controls vs Annex A AI Controls Roughly a third of ISO 42001’s Annex A maps onto something in ISO 27001. Supplier controls (A.10), data classification and handling (A.7), and roles and responsibilities (A.3) reuse work you’ve already done. The impact assessment group (A.5), most of the lifecycle group (A.6), and the transparency obligations to interested parties (A.8) have no ISO 27001 equivalent, and that’s where most of the new effort goes. Who Asks for Each Certificate Procurement teams ask for ISO 27001 or SOC 2 by default. ISO 42001 comes up when a buyer’s vendor questionnaire has grown an AI section: does a human review high-stakes outputs, do you track which third-party models touch customer data, have you run an impact assessment? A 42001 certificate answers most of that before the security call even starts. Boards and regulators in the EU and the Gulf are the other main source of demand. Worth Knowing: Both standards use ISO’s Harmonized Structure Both standards use ISO’s Harmonized Structure, so clauses 4 through 10 (context, leadership, planning, support, operation, performance evaluation, improvement) share the same numbering and mostly the same wording. An auditor moving between them sees the same management-system skeleton with a different set of risks and controls hung on it. Where ISO 42001 and ISO 27001 Overlap The Shared Harmonized Structure (Clauses 4 to 10) The management-system machinery carries over almost untouched. Document control, competence records, the internal audit program, management review, corrective action, and the way you plan for risks
If your ISO 27001 certificate covers all of your health and care data processing, the NHS Data Security and Protection Toolkit does two useful things with it. It marks the applicable evidence items as complete on its own, and it shrinks the scope of any independent audit to whatever your certification doesn’t already cover. A certified vendor who does the mapping properly walks into a DSPT submission with most of the technical and organizational evidence already written, already audited, and already versioned. What ISO 27001 won’t do is get you out of the DSPT. It says nothing about the NHS-specific information governance items, clinical safety, the national data opt-out, or Caldicott principles. Vendors who assume “certified means done” usually discover this in the last two weeks of June. This piece is for the founder, CTO, or ops lead at a UK health-tech company who owns compliance without being a compliance person. It covers what each framework asks for, which Annex A controls line up with which DSPT requirements, which evidence you can reuse as-is, which needs reframing around patient data, and a five-step workflow for turning an existing ISMS into a DSPT submission. One more thing on timing: NHS England published DSPT version 9 for the 2026/27 cycle on 4 September 2026, and the submission deadline is 30 June 2027. So this exercise belongs in your calendar now, not next spring. Understanding the Two Frameworks at a Glance What ISO 27001:2022 Covers ISO/IEC 27001:2022 is the international standard for an Information Security Management System (ISMS). It comes in two halves. Clauses 4 to 10 define the management system itself: context, leadership, risk assessment and treatment, resourcing, operation, performance evaluation, and continual improvement. Annex A lists 93 reference controls across four themes (organizational, people, physical, technological). Your Statement of Applicability (SoA) records which of those controls you apply, which you exclude, and why. An accredited certification body issues the certificate after a two-stage audit, then you keep it through annual surveillance audits and a three-year recertification cycle. The certificate covers a defined scope, and that scope statement is the first thing a DSPT assessor reads. What the NHS DSPT Requires in 2026/27 The Data Security and Protection Toolkit (DSPT) is NHS England’s annual online self-assessment for every organization that touches NHS patient data or systems. It’s a contractual requirement under the NHS Standard Contract. Your published status (“Standards Met”, “Standards Exceeded”, “Approaching Standards”, “Standards Not Met”) is publicly searchable, so procurement teams and prospective NHS customers do look it up. The Toolkit isn’t one assessment. NHS England tailors it by organization category, and your category decides which assertions you answer and whether you need an independent audit. Version 9 came out on 4 September 2026. The Category 1 view is aligned to CAF version 4.0, and the whole thing closes on 30 June 2027. Insider Note: Most health-tech SaaS vendors are Category 3, not Category 2. To be an IT Supplier you need all three things at once: digital goods or services to the NHS, 50 or more staff, and £10 million or more in turnover. Picking “IT Supplier” because you sell NHS-facing software, without hitting the size thresholds, lands you in a heavier evidence set and a mandatory audit you may not need. Check the category before you check anything else. Key Structural Differences Between ISO 27001 and DSPT Four differences matter when you’re trying to reuse evidence. What they’re about. ISO 27001 is an information security standard. The DSPT is an information governance standard that includes security. A good chunk of it deals with lawful basis, transparency, data subject rights, records management, and the SIRO and Caldicott Guardian roles. None of that is in Annex A. How you’re assured. ISO 27001 gets certified once and surveilled once a year by an accredited body. The DSPT starts from a blank submission every year, and Category 1 and 2 organizations get independently assessed every year too. How granular they are. Annex A controls read as objectives (“access rights shall be provisioned, reviewed, modified and removed”). DSPT evidence items read as things to upload (“a list of all systems that hold personal data, with the date of last review”). So the mapping runs many-to-one in both directions. Where they’re heading. Since 2024/25 NHS England has been moving the Toolkit onto the NCSC Cyber Assessment Framework (CAF). CAF is outcome-based: assessors score you Achieved, Partially Achieved, or Not Achieved against an NHS England profile, rather than accepting a policy upload as proof. Category 1 organizations are already there. Category 2 and 3 are still on assertions and evidence, but NHS England has said CAF alignment will reach more organization types over time. The Business Case for Reusing ISO 27001 Evidence in DSPT How Much of DSPT Can Realistically Be Satisfied by ISO 27001 Controls For a Category 2 or 3 vendor with a full-scope ISO 27001 certificate, expect 60 to 75 percent of the mandatory evidence items to come from ISMS artifacts, either automatically (where the Toolkit auto-completes them) or with some light reframing. The rest is NHS-specific governance and information governance content that ISO 27001 doesn’t touch. The NHS’s own guidance treats reuse as a scope question. The DSPT help pages say an ISO 27001 certification must cover all health and care data processing to receive the full exemption, and that a certificate scoped only to an IT department is good evidence for many of the IT questions but not all of them. If your certificate says “the SaaS platform hosted in AWS eu-west-2” and NHS data also passes through your support desk tooling, your analytics sandbox, and a contractor’s laptop, the auto-completion won’t apply. Your assessor will want to know how those flows are controlled. Time and Cost Savings for Health-Tech Vendors There’s no fee to submit the DSPT. The cost is internal time, plus, if you’re Category 2, the independent audit and the annual penetration test the mandatory assertions expect. Building a first DSPT submission from nothing usually takes
Most companies start their first SOC 2 or ISO 27001 project in a spreadsheet, only to have it fall apart in week 6. This is typically when they’ll call us asking us to implement a GRC system that scales. Excel holds 154 controls fine. The trouble starts when an auditor sends over an evidence request list, two frameworks need updating at once, and a control owner who hasn’t opened the file since March edits the wrong row. This article gives you a free GRC workbook template built to take into consideration the hundreds of engagements we’ve guided. It walks you through each tab and tells you plainly when you’ve outgrown it. We’ve worked with hundreds of companies implementing SOC 2 + ISO 27001 and to be honest, for 80% of cases, using excel is feasible and even advised. Its a tool most of the staff knows and using it cuts onboarding times from weeks to a few hours. It also makes it accessible to the whole organization. The workbook covers all 33 SOC 2 Common Criteria plus the Availability, Confidentiality, Processing Integrity, and Privacy criteria, all 93 ISO 27001:2022 Annex A controls, a crosswalk between the two, and the evidence, risk, policy, and gap trackers that sit around them. It’s free, there are no macros, and it opens in Excel or Google Sheets. Why Start SOC 2 and ISO 27001 Tracking in a Spreadsheet The obvious argument for using Excel is cost and ease of use. A GRC platform costs around $10,000 a year before you’ve put a single control in place, and it pushes you into its control library and its workflow before you understand your own environment. A spreadsheet costs nothing and holds exactly the columns you need. More usefully, it makes you think about scope, ownership, and evidence before you automate any of it, and that thinking is the part no platform does for you. There’s a less obvious reason too. Teams that build their first control inventory by hand understand it. They know why CC6.3 maps to A.5.18, why the offboarding checklist is evidence for both, and who actually owns it. Teams that inherit a pre-populated platform library often don’t, and it shows in audit interviews when the auditor asks a control owner to explain a control they’ve never read. When a GRC Workbook Makes Sense A spreadsheet is the right tool when you’re chasing one or two frameworks, your team is under about 50 people, and one person owns compliance day to day. It also suits the readiness phase for any company. Scoping, gap analysis, and control design all go faster in a workbook than in a platform because there’s nothing to configure first. If you’re aiming for a SOC 2 Type I, or an ISO 27001 certificate with a tightly bounded ISMS scope, the workbook can carry you all the way to the audit. When You’ve Outgrown Excel (and Need a Platform) Excel breaks at scale in predictable ways. Spreadsheet research going back decades keeps finding that most operational spreadsheets contain at least one error; a review of field audits across 88 operational spreadsheets found errors in 94% of them. A compliance workbook with 1,400 formulas and a dozen editors isn’t exempt. Add a Type II observation period, where you collect the same evidence every month for a year, and manual tracking stops being a discipline and becomes someone’s full-time job. The specific tripwires are covered later in the article, but the short version is that when evidence collection becomes the bottleneck, it’s time to stop. What’s Inside the Free GRC Workbook Template The workbook has nine tabs. Eight get their own section in the walkthrough below; the ninth, Gap Analysis, is a remediation log that feeds the dashboard. Every tab uses the same color convention. Navy headers mean pre-filled reference content. Teal headers with light yellow cells are the fields you fill in. Grey headers are formula columns, and you should leave those alone. SOC 2 Trust Services Criteria Coverage All 61 criteria from the AICPA 2017 Trust Services Criteria (with the 2022 revised points of focus) are already in there: the 33 Common Criteria across CC1 through CC9, plus Availability (3), Confidentiality (2), Processing Integrity (5), and Privacy (18). Each row has a plain-English summary of what the criterion expects, so a control owner who has never opened the AICPA document can still understand what they’re being asked to prove. ISO 27001 Annex A Controls Coverage All 93 Annex A controls from ISO/IEC 27001:2022 are listed under their four themes: Organizational (37), People (8), Physical (14), and Technological (34). Each control has a short description of what it covers and a pre-computed column showing which SOC 2 criteria relate to it. Unified Control Mapping Between SOC 2 and ISO 27001 The Crosswalk tab maps every SOC 2 criterion to the Annex A controls and ISO clauses it overlaps with, labels the overlap as Shared, Partial, or SOC 2-specific, and pulls the live status and evidence IDs from the SOC 2 tab. A second table lists the 13 Annex A controls that have no meaningful SOC 2 counterpart, so you know what to track on its own. Evidence Tracker Every piece of evidence gets one row, tagged to the SOC 2 criteria and ISO controls it supports, with an owner, a source system, a location, the period it covers, and how often you collect it. A formula works out the next due date and flags each item as Current, Due Soon, Overdue, or Not Scheduled. Owner and Status Fields Both control tabs have a Control Owner column and a Status dropdown with five defined states: Not Started, In Progress, Implemented, Needs Remediation, and Not Applicable. The definitions sit on the Overview tab so that two people setting a status on the same day mean the same thing by it. Risk Register Tab Likelihood and impact on a 1 to 5 scale, an automatic score, a rating (Critical, High, Medium, Low), a treatment
ISO/IEC 27001 certificates nearly doubled in a single year, from 48,671 in 2023 to 96,709 in 2024, according to ISO’s own certification survey. A big share of that jump comes from startups, not enterprises. The reason is simple: buyers stopped taking “we take security seriously” at face value, and a certificate is the fastest way to prove it. This guide covers when a startup should pursue ISO 27001, what it costs, how long it takes, and how a small team gets certified without a dedicated security department. What Is ISO 27001 and Why It Matters for Startups ISO/IEC 27001 is the international standard for information security management. It doesn’t hand you a checklist of firewalls to buy. Instead, it asks you to build and run an Information Security Management System (ISMS): a documented, repeatable way of finding your security risks and doing something about them. Certification means an accredited third party checked that your ISMS works and matches the standard. For a startup, that distinction matters. You’re not being graded on whether you own expensive tools. You’re being graded on whether you can show a system, which is exactly what an enterprise buyer’s procurement team wants to see before they sign. The Core Principles: Confidentiality, Integrity, and Availability Everything in ISO 27001 traces back to the CIA triad: confidentiality, integrity, and availability. Confidentiality means only the right people see the data. Integrity means the data is accurate and hasn’t been tampered with. Availability means the data is there when someone needs it. Every control you put in place, and every risk you assess, ties back to protecting one of those three properties. ISO puts it plainly: an ISMS that meets the standard preserves the confidentiality, integrity, and availability of information by running a risk management process. Keep the triad in mind, and the rest of the framework stops feeling abstract. How ISO 27001 Differs from Other Security Frameworks for Early-Stage Companies SOC 2 is the framework startups usually bump into first, especially when selling into the US. It results in an attestation report from a CPA firm, scoped to specific systems. ISO 27001 is a certification, recognized in over 150 countries, and it covers your whole organization through a formal ISMS with management reviews and company-wide risk assessment. The two overlap heavily. Roughly 70 to 80 percent of the controls line up, so if you do one, the second gets much cheaper. The real difference is structure. SOC 2 checks whether specific controls work. ISO 27001 checks whether you’ve built a management system that keeps those controls working over time. It also aligns closely with GDPR, which is why it travels well in Europe. Insider Note: Auditors can usually tell within an hour whether your ISMS is real or was assembled the week before the audit. A management review meeting with actual notes, decisions, and follow-ups from three months ago is worth more than a perfect-looking policy binder with no evidence anyone ever used it. When Should a Startup Pursue ISO 27001 Certification? The honest answer: when a deal, a market, or an investor is asking for it, or is about to. Certifying purely because it feels responsible is a good way to burn cash and calendar time you don’t have yet. Early-Stage vs. Growth-Stage: Timing the Certification At pre-seed and seed, ISO 27001 is usually early unless you’re selling into regulated industries or the EU from day one. Your product and processes are still shifting, and certifying a moving target means re-documenting everything a quarter later. At Series A and beyond, the math changes. Deals get bigger, buyers get more careful, and investor due diligence starts probing your security posture. Certifying while you’re 15 to 40 people is often the sweet spot: mature enough to have stable processes, small enough that scoping the ISMS is still manageable. When ISO 27001 Might Be Overkill for Your Startup If your customers are US SMBs who only ever ask for SOC 2, leading with ISO 27001 may be solving a problem you don’t have. If you’re pre-revenue and still hunting for product-market fit, your time is better spent shipping. And if no one in your sales pipeline has ever mentioned a certificate, that silence is data. Pro Tip: Pull your Last 20 Security Questionnaires Before you commit, pull your last 20 security questionnaires or RFPs and count how many explicitly asked for ISO 27001 versus SOC 2 versus nothing. That single tally answers the “which framework, and when” question faster than any consultant’s discovery call. Key Benefits of ISO 27001 for Startups Unlocking Enterprise Sales and Bigger Deals The clearest return is revenue you couldn’t touch before. Large buyers often won’t even start a security review without a recognized certificate on file. ISO 27001 gets you past the first gate of enterprise sales, and it shortens the review itself because a big chunk of the questionnaire is already answered by your certification. Building Investor and Board Confidence Certification signals operational maturity. When an investor sees a functioning ISMS, they see a founder who can build systems, not only ship features. That plays well in investor due diligence, where a security gap can stall a term sheet, and it gives your board something concrete to point to on risk. Establishing Customer Trust from Day One A certificate is third-party proof, and third-party proof beats self-assurance every time. For a young company with no brand equity yet, it’s a shortcut to being taken seriously by customers who’ve never heard of you. Creating a Scalable Security Foundation Because ISO 27001 makes you build a system rather than a one-off fix, it scales as you grow. New hires, new products, and new data types slot into an ISMS you already run. You’re not rebuilding security from scratch at every stage. Reducing Long-Term Compliance Costs Adding SOC 2, HIPAA, or ISO 42001 later is far cheaper once an ISMS exists, thanks to that 70 to 80 percent control overlap. The first framework is the expensive one.
After a SOC 2 and ISO 27001 engagement, there are two documents out of the whole pile that actually close deals: the SOC 2 attestation report and the ISO 27001 certificate. Everything else your engagement produces exists to create those two, support them, or keep them alive for another year. Companies routinely ask their auditor for a SOC 2 certificate, which doesn’t exist. They send a prospect their full ISMS documentation when a one-page certificate would have done. They pay for six months of readiness work and then can’t say what they’re holding at the end of it. So here’s the full list. What a SOC 2 engagement produces, what an ISO 27001 engagement produces, what a combined program produces, and who gets to see each one. Understanding SOC 2 and ISO 27001 Engagement Outputs The Core Difference: Report vs. Certificate SOC 2 is an attestation. A licensed CPA firm examines your controls against the Trust Services Criteria under standards set by the AICPA, then writes up what it found and signs an opinion. No certificate. No logo from the AICPA. No pass or fail stamp. What you get is the report, and it usually runs 60 to 120 pages. ISO 27001 is a certification. An accredited certification body audits your Information Security Management System (ISMS) against ISO/IEC 27001:2022, and if you conform, it issues a certificate of registration. The certificate itself is a page or two. All the detail lives behind it, in your ISMS documentation and the audit reports the certification body writes as it goes. SOC 2 Engagement Deliverables The SOC 2 Attestation Report The report is the engagement. The AICPA’s illustrative SOC 2 report lays out the standard structure: auditor’s report, management’s assertion, system description, the Trust Services Criteria in scope, and the controls tested with their results. A Type I covers control design at one point in time. A Type II covers whether those controls actually operated over a period, usually three to twelve months, and most enterprise buyers now won’t accept anything else. Independent Auditor’s Opinion Letter First section of the report, and the first thing anyone experienced turns to. It gives the scope, the examination period, and the auditor’s conclusion. An unqualified opinion means the description held up and the controls worked. A qualified opinion means the auditor found something material, and every serious reviewer will want to talk about it. Management Assertion Your leadership signs a written statement stating that the system description is accurate and that the controls were properly designed and are operating. It reads like a formality, and it isn’t. The auditor’s entire examination runs against what management asserts here, so overstating anything creates real exposure. System Description Usually the longest part of the report, and you write it, not the auditor. It covers the services in scope, your infrastructure, software, people, processes, how data moves, which subservice organizations you depend on, and the complementary user entity controls your customers have to run on their side for your controls to hold up. Trust Services Criteria Applied Security (the Common Criteria) is in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional, and the report names exactly which ones you picked. Whatever you decide during scoping ends up printed in a document your customers read for the next several years. Description of Tests of Controls and Results (Type II) The matrix: every control, what the auditor did to test it, and what came back, including exceptions. Reviewers spend most of their time here, because the exceptions tell them things the opinion letter won’t. Bridge Letter / Gap Letter Your report covers a fixed window, so one ending December 31 leaves a hole for a customer doing diligence in June. A bridge letter from your management, not the auditor, confirms that nothing material changed in the control environment between the report’s end date and today. You’ll write these often enough to keep a template. Management Letter and Observations Plenty of auditors also send an internal-only letter covering observations, minor exceptions, and suggestions that never reached the threshold of a qualified opinion. It’s the closest thing to free consulting you’ll get before next year’s audit starts. Insider Note: Ask early whether your auditor issues a management letter, and whether exceptions land in the report body or only in that letter. Firms handle this differently, and the answer decides what your customers see versus what stays behind your firewall. It rarely comes up in the proposal, but it changes how the finished report reads to a buyer. ISO 27001 Engagement Deliverables ISO 27001 Certificate of Registration The document everyone asks for. It names the certified legal entity, states the ISMS scope, identifies the certification body, carries an accreditation mark from a body recognized under the International Accreditation Forum such as UKAS or ANAB, and shows the validity dates. It’s good for three years as long as you pass annual surveillance audits. Read the scope statement carefully, on your own certificate as much as anyone else’s. A certificate covering one office or one product line says nothing about the rest of the business. Statement of Applicability (SoA) After the certificate, this is the document buyers request most. The Statement of Applicability runs through all 93 Annex A controls in ISO/IEC 27001:2022, says which apply to you, justifies the ones you excluded, and records where each stands. Auditors use it as the map of your control environment, and larger customers increasingly want to see it or a summary of it during diligence. Risk Assessment and Risk Treatment Plan Your methodology, the register it produced, and the Risk Treatment Plan showing what you decided to do about each significant risk: mitigate it with a control, transfer it, avoid it, or accept it. ISO 27001 is built around risk, so these documents are what justify every control decision recorded in the SoA. Information Security Management System (ISMS) Documentation The policy and procedure set, plus the operational records that prove any of it happens. Information
Two controls decide whether your ISO 27001 business continuity plan survives an audit: Annex A 5.29 and Annex A 5.30. One keeps your security controls working while everything else is failing. The other gets your systems back online before the damage becomes permanent. Plenty of teams write a continuity policy that satisfies neither in the way a certification auditor expects, and they discover the gap during the Stage 2 audit, when it is expensive to fix. This article covers what ISO 27001:2022 actually requires for business continuity, the components an auditor will ask to see, the step-by-step build, and the mistakes that turn a continuity plan into a non-conformity. What Is an ISO 27001 Business Continuity Plan? An ISO 27001 business continuity plan is the documented set of procedures that keeps information security effective and critical ICT services available during a disruption. It is not a generic “keep the lights on” binder. Under ISO 27001, the plan protects the confidentiality, integrity, and availability of information when normal operations break down: a ransomware event, a cloud outage, a data center failure, or a supplier collapse. The plan lives inside your Information Security Management System (ISMS). It draws on your risk assessment, your asset register, and your Business Impact Analysis (BIA), and it feeds your disaster recovery procedures. Scope is the part people get wrong. ISO 27001 cares about the information security aspects of continuity, not every operational hiccup a full business continuity program might cover. Why You Need a Business Continuity Plan for ISO 27001 Compliance Downtime is expensive, and the bill arrives fast. For most organizations, the question is not whether a disruption will happen, but how quickly they recover when it does. There is also a hard compliance reason. You cannot certify to ISO 27001 while ignoring continuity. The standard requires you to maintain information security during disruption and to keep ICT able to support recovery, and an auditor will ask for the evidence. A continuity plan is where availability stops being a promise and becomes a tested capability. Let Axipro help you build a business continuity plan that’s practical, compliant, and audit-ready. Strengthen Your Business Continuity Strategy Schedule A Consultation ISO 27001 Requirements Related to Business Continuity Planning ISO/IEC 27001:2022 carries 93 Annex A controls across four categories: organizational, people, physical, and technological. Continuity sits in the organizational set, and two controls do the heavy lifting, supported by two more on the technical side. Annex A 5.29 – Information Security During Disruption A.5.29 requires you to maintain information security at an appropriate level when a disruption hits. The point is that security controls have a habit of degrading under pressure. People disable multi-factor authentication to “speed things up,” logging stops on a failover system, or access controls loosen while everyone scrambles. A.5.29 says the confidentiality and integrity of your information must be maintained even while availability is under threat. It is classed as both a preventive and a corrective control, meaning it should reduce the chance of an incident and also help resolve one already underway. Annex A 5.30 – ICT Readiness for Business Continuity A.5.30 is the technical engine. It requires that your ICT readiness is planned, implemented, maintained, and tested against business continuity objectives and ICT continuity requirements. In plain terms, your servers, networks, applications, and cloud services need a defined recovery path, each with a Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and you need to prove the path works. This control is entirely new in the 2022 revision. It has no precedent in ISO 27001:2013, which is exactly why teams migrating from the older version so often have a gap here. Important: A.5.30 did not exist in ISO 27001:2013. If your continuity documentation was written against the old Annex A 17 cluster and never updated, you are missing a control the auditor will specifically test. Treat ICT readiness as a fresh requirement, not a relabel. Two technological controls back these up. Annex A 8.13 (Information Backup) requires backups to be taken and tested in line with an agreed policy, and Annex A 8.14 (Redundancy of Information Processing Facilities) covers the failover and redundancy that let critical systems keep running when a component dies. Relationship Between ISO 27001 and ISO 22301 This is where confusion is common. ISO 27001 requires the information security aspects of continuity. ISO 22301 is the dedicated standard for a full Business Continuity Management System (BCMS), covering people, facilities, supply chain, and operations far beyond information security. An ISO 27001 certificate does not certify your wider continuity program. The good news: both standards share the Annex SL high-level structure, so risk assessment, internal audit, management review, and document control carry across. Teams that already run ISO 27001 can layer ISO 22301 on top with far less effort than starting from scratch. Key Components of an ISO 27001 Business Continuity Plan Business Impact Analysis (BIA) The BIA is the foundation. It identifies your critical business processes, the ICT systems they depend on, and the cost of losing each one over time. It is where your recovery objectives come from, not from a vendor datasheet. A BIA also sets the Maximum Tolerable Period of Disruption (MTPD): the point beyond which an activity’s failure causes unacceptable damage. Risk and Disruption Scenario Assessment Your risk assessment identifies what could cause a disruption and how likely it is, feeding the Risk Treatment Plan and the Statement of Applicability (SoA) that records which controls apply. Continuity planning then runs concrete scenarios: ransomware, a regional outage, a key supplier failure, the loss of a data center. Response and Recovery Strategies For each critical system, you define how you will respond and recover: failover to a secondary site, restore from backup, or switch to a manual workaround. This links incident response to crisis management, the executive-level decision-making that kicks in when an incident escalates beyond a routine fix. Roles and Responsibilities Name real people, not departments. “IT will handle it” is the single most common
Most companies pursuing ISO 27001 certification cost analysis for the first time will spend between $10,000 and $50,000 in year one, and far less than half of that goes to the auditor. A 50-person SaaS company typically pays $10,000 to $22,000 in certification body fees alone, then doubles or triples that figure in implementation work, tooling, and internal hours before the Stage 2 audit even begins. The wide range exists because ISO 27001 certification cost is not a price tag; it is the sum of a dozen separate decisions: your scope, your security maturity, your certification body, and whether you build the ISMS yourself, hire a consultant, or run it through a compliance automation platform. This article breaks down every one of those costs, stage by stage and region by region, including the ones that never appear in vendor quotes. What Determines ISO 27001 Certification Cost? Six variables drive almost all of the variance between a $10,000 certification and a $150,000 one. Company Size and Employee Count Headcount is the single biggest cost driver because certification bodies calculate audit days (mandays) primarily based on the number of people working within the scope of your Information Security Management System (ISMS). The calculation is not arbitrary: accredited bodies follow the audit time tables in ISO/IEC 27006, which means a 20-person company and a 200-person company will receive structurally different quotes no matter how hard they negotiate. More employees also means more interviews, more evidence sampling, and more Annex A controls applied across more people. Scope and Complexity of the ISMS Scope is the variable you actually control. Your Statement of Scope defines which business units, systems, products, and locations fall inside the ISMS. A scope limited to one product line and the engineering team that runs it costs dramatically less to implement and audit than a whole-of-company scope. Complexity compounds this: bespoke infrastructure, regulated data types, and heavy third-party dependency chains all add controls, evidence, and audit time. Number of Physical and Cloud Locations Each physical site within scope can require its own audit visit, with travel costs on top. Multi-site organisations can reduce this through sampling (more on the square root rule later), but every additional location still adds something. Cloud environments count too: multiple cloud providers, regions, and tenancy models expand the technical scope auditors must cover, even when no travel is involved. Existing Security Maturity A company that already runs access reviews, maintains an asset inventory, and documents its incident response process is buying a much shorter journey than one starting from a blank page. The gap analysis exists precisely to price this difference. Organisations already aligned to SOC 2, NIST CSF, or Cyber Essentials Plus typically reuse 50 to 70 percent of their existing controls and evidence, which translates directly into lower implementation cost. Choice of Certification Body Certification bodies are not interchangeable on price. Large international names like BSI, Bureau Veritas, LRQA, and DNV charge premium day rates, often 30 to 50 percent above smaller accredited bodies, and their brand carries weight with enterprise procurement teams. What matters most is accreditation: a certificate issued by a body accredited by UKAS, ANAB, or another IAF (International Accreditation Forum) member carries international recognition. An unaccredited certificate is cheaper and close to worthless in serious sales conversations. Internal vs. External Implementation Approach The final driver is who does the work. Internal teams cost salary hours. Consultants cost fees. Platforms cost subscriptions. Each approach lands at a very different total, which is why this article dedicates a full section to it below. Average ISO 27001 Certification Cost Ranges The ranges below cover total first-year cost: implementation, tooling, and certification audits combined. They assume an accredited certification body and a sensibly defined scope. Cost for Small Businesses and Startups (1–50 Employees) A focused startup with a single product, cloud-native infrastructure, and a tight scope can realistically certify for $10,000 to $35,000 all-in. Lean implementations using templates or an automation platform sit at the bottom of that range. UK micro-businesses can find UKAS-accredited audit fees starting around £6,250, with day rates near £1,250. Cost for Mid-Sized Organizations (50–250 Employees) This is where most certifications happen, and where costs spread widest. Expect 8 to 12 initial audit days, $30,000 to $80,000 in total first-year spend, and a six to nine month timeline. Multiple departments, more mature customer requirements, and the first real multi-team coordination overhead all show up in the budget. Cost for Large Enterprises (250+ Employees) Enterprise certifications routinely exceed $100,000 in year one once you include program management, multiple sites, and large-scale audits. The audit fee alone can pass $50,000 for complex, multi-site scopes. At this scale, the internal time investment, covered under hidden costs below, often outweighs every external invoice. ISO 27001 Cost Breakdown by Stage Here is where the money actually goes, in roughly the order you will spend it. Cost of Purchasing the ISO 27001 Standard The official ISO/IEC 27001:2022 document costs CHF 155 (roughly $170) from the ISO store. Most teams also buy ISO 27002, the implementation guidance for the Annex A controls, for a similar amount. Budget $300 to $400 for both. Do not skip this purchase: implementing against second-hand summaries of the standard is a common source of audit findings. Gap Analysis Costs A consultant-led gap analysis before committing to anything else runs $2,000 to $10,000 depending on scope, while platform-based readiness assessments are often bundled into the subscription. The output, a clear map of where you stand against every clause and control, is what makes the rest of the budget predictable. ISMS Implementation Costs This is the largest and most variable line item: building the risk assessment, the risk treatment plan, the Statement of Applicability (SoA), and operationalizing the controls you have selected. Done internally, it consumes 200 to 600 hours of staff time over four to eight months. Done with consultants, expect $10,000 to $50,000 in fees for a typical SMB. Documentation and Policy Development Costs ISO 27001 requires a defined set of documented
Researchers who buy second-hand drives off online marketplaces keep finding the same thing: live data. A widely cited study by Blancco Technology Group found that 42% of used drives sold on eBay still held recoverable information, including financial records and personal data the previous owners assumed was long gone. The drives were not hacked; they were thrown away by organizations that treated deleting a file as the same thing as destroying it. Secure data disposal is where many compliance programs fail. ISO 27001, SOC 2, and GDPR all demand it, but they describe it in different languages, enforce it through different mechanisms, and punish failure in very different ways. This article sets out what each framework requires, where the requirements overlap, and how to run a single disposal program that satisfies all three at once. Why Secure Data Disposal Matters Across Compliance Frameworks Disposal is the last link in the data lifecycle, and the easiest one to skip. An organization can run flawless access controls, encryption, and monitoring for years and still cause a reportable breach the moment one unwiped laptop leaves the building. A recoverable drive in a recycling skip is functionally identical to an open database on the internet, and auditors and regulators know it. Most disposal failures are unforced errors: a control that was already written into policy but never carried through to the actual hardware. The gap between having a disposal policy and proving this specific drive was destroyed is exactly where audits and breach investigations live. Defining Secure Data Disposal: Key Terms and Concepts What Is Secure Data Disposal? Secure data disposal is the end-to-end process of removing data and the equipment that holds it from active use, in a way that prevents its recovery. It covers the full lifecycle end: deletion of data while a system is still live, sanitisation of media that will be reused, physical destruction of media that will not, and the safe handling of equipment that is recycled, returned to a lessor, or sold. Disposal is the goal. The methods are how you get there. What Is Secure Data Destruction? Secure data destruction is the subset of disposal that renders media permanently unusable or its contents mathematically irretrievable. Shredding a drive, pulverising it, incinerating it, or destroying the encryption keys that make an encrypted disk readable are all forms of destruction. Destruction is one route to disposal, and it is the right route when the data is highly sensitive, or the media will never be reused. Secure Data Disposal vs. Secure Data Destruction: What Is the Difference? The distinction matters more than it looks. Disposal is the outcome you owe to every framework: data gone, unrecoverable, equipment handled appropriately. Destruction is just one of the methods. You can dispose of data without destroying the hardware by sanitising a drive thoroughly enough to reuse it. Confusing the two leads to two classic mistakes: destroying assets that could have been securely wiped and reused, and assuming a quick deletion counts as disposal when it does not. Important: Emptying the recycle bin, formatting a drive, or hitting delete does not dispose of data under any of these frameworks. Standard deletion only removes the pointer to the data; the bits remain until they are overwritten. Every framework discussed here expects the data to be unrecoverable, which is a far higher bar than not visible. What ISO 27001 Requires for Secure Data Disposal ISO/IEC 27001 handles disposal through a small cluster of Annex A controls that auditors read as a single process rather than in isolation. The two controls that do most of the work are 7.14 and 8.10. For a deeper look at how these controls fit into a broader compliance program, see our ISO 27001 implementation guide. ISO 27001 Annex A 7.14: Secure Disposal or Re-Use of Equipment Annex A 7.14 is a physical control. Before any equipment is disposed of or reused, the organisation must check whether it holds information assets or licensed software and ensure those are permanently erased or the media physically destroyed. It applies to servers, laptops, desktops, mobile devices, printers, network gear, and any storage media: if it ever processed information, it is in scope. The control replaces the older 2013 clause 11.2.7 and adds explicit expectations around removing identifying markings and handling end-of-occupancy scenarios. ISO 27001 Control 8.10: Information Deletion Annex A 8.10 is a technological control, and it focuses on the data rather than the box. It requires information stored in systems, devices, or media to be deleted when it is no longer required, and rendered unrecoverable. The cleanest way to keep these straight: 8.10 governs the data while it is in use or reaches its retention limit; 7.14 governs the hardware at end of life. Most retention-driven deletion sits under 8.10; most decommissioning sits under 7.14. ISO 27001 Control 8.12: Data Leakage Prevention and Its Role in Disposal Control 8.12 is rarely filed under disposal, but improperly discarded media is one of the oldest data leakage channels there is. A drive that leaves your control with recoverable data on it is a leak, regardless of how it left. Treating disposal as part of your leakage prevention posture forces the right question at the right time: what could walk out the door on this device, and has it actually been removed? Physical Destruction and Irretrievable Erasure Under ISO 27001 ISO 27001 offers two broad routes: physically destroy media that holds information, or erase and overwrite it so retrieval by a malicious party is precluded. The standard cross-references ISO/IEC 27040 for detailed sanitisation methods. The unifying requirement is that recovery should be impractical, not merely inconvenient. Deletion alone never satisfies this. Overwriting, Full-Disk Encryption, and Other Approved Methods Overwriting user-accessible storage with multiple passes is acceptable for many sensitivity levels. Full-disk encryption changes the economics of disposal entirely: if a device is encrypted from day one and the keys are properly managed, secure disposal can be as simple as destroying the keys, a technique known as
