Can a SaaS company get ISO 27001 for its product and what does it cost in time and money?
A SaaS company can get ISO/IEC 27001:2022 certification for its information security management system (ISMS) built around its product and the services that support it, such as hosting, support, release management and customer operations. Certification is issued only by an accredited certification body after an independent audit, and the cost and timeline depend on the scope chosen, the headcount in that scope and how mature the evidence already is. Enterprise buyers usually ask for the certificate because their own vendor risk teams cannot test every SaaS provider directly, so the first question is which services the certificate must cover. The organization owns its controls, policies and decisions. An implementation partner such as DeployOpen can plan, configure and harden the self-hosted or cloud-hosted systems inside the scope, and prepare the records that show each control operating, such as access reviews, change tickets, backup restore tests and logs. The auditor then tests that evidence and, if it meets the requirements, the certification body issues the certificate. Before committing, ask any provider for a written scope, a named list of in-scope systems and a breakdown of who is paid for what, including the certification body's audit days and any recurring surveillance audits.
Two cost drivers matter most for a SaaS company. The first is how many people and systems fall inside the scope, since audit time follows the size of the ISMS. The second is evidence maturity: a team that already runs infrastructure as code, centralized logging and ticketed change management will spend far less effort producing evidence than one that must reconstruct it for an audit. Costs are one-time for the initial implementation and certification audits, and recurring for internal reviews, surveillance audits and upkeep. Certification follows a three-year cycle under ISO/IEC 17021-1, with at least one audit in every calendar year, so budget for the recurring portion for the full cycle, not only the first audit. Timelines are also set by the transition rules. All ISO/IEC 27001:2013 certificates had to expire or be withdrawn by 31 October 2025, so any company citing a 2013-based certificate in a contract must confirm it is current. Ask the certification body to confirm its accreditation and that it applies ISO/IEC 27006-1:2024 to clients, a requirement IAF MD 29:2024 set for all clients by 31 March 2026.
How the ISO 27001 certification process runs for a SaaS product
The sequence moves a SaaS product from a defined scope to an accredited certificate and then keeps it valid through annual surveillance. Each phase produces a specific output that the next phase depends on.
Define the scope around the product
The organization, with its implementation partner if it has one, decides which services, platforms, sites, teams and cloud accounts fall inside the ISMS. For a SaaS company this usually means the production service, its supporting cloud accounts, the engineering and support teams that operate it, and the customer data it stores. The output is a written scope statement and an initial list of interfaces with out-of-scope systems. The step is done when leadership signs off the scope and the certification body agrees it matches the product as sold. Clause 1 does not allow dropping any requirement in clauses 4 to 10, so the scope narrows what is covered, not how the management system works.
Run the gap assessment and remediate
Compare current practice against each clause of ISO/IEC 27001:2022 and each Annex A control that applies to the scoped service. Typical gaps for SaaS teams include undocumented access reviews, no formal risk register, unclear ownership of cloud accounts and missing supplier assessments. Engineering teams usually close technical gaps, such as logging, backups and access controls, while leadership and compliance owners handle policies and risk decisions. The output is a remediation plan and a register of gaps with owners and due dates. The step is done when each gap is either closed with evidence or recorded with a planned fix.
Write the risk assessment and Statement of Applicability
The organization sets its information security risk assessment and risk treatment methods, identifies risks to the scoped service and selects controls. The Statement of Applicability records each Annex A control, whether it applies, and why. For SaaS, the cloud services control A.5.23 and the controls on secure development and supplier relationships usually carry the most detail. The output is an approved risk register, risk treatment plan and Statement of Applicability. The step is done when management reviews and approves these documents and they match the systems the auditor will sample.
Pass the stage 1 documentation review
The certification body's auditors review the ISMS documentation against the standard, usually remotely, to confirm the design is in place and ready for testing. They check the scope, policies, risk assessment, Statement of Applicability, internal audit and management review records, and whether the organization understands its context and interested parties. Auditors record findings that must be fixed before stage 2. The output is a stage 1 report and a list of items to address before the implementation audit. The step is done when the organization closes the stage 1 findings and the certification body confirms the audit can proceed. Ask the certification body how it plans stage 1 and what it expects to see in advance.
Complete the stage 2 implementation audit
Auditors test whether the controls described in the documentation operate in practice. For a SaaS product, this means sampling access approvals, change records, incident tickets, backup restore tests, supplier reviews, logging configurations and employee onboarding and offboarding records. Auditors interview engineers, support staff and managers, and they may look at cloud configurations directly. Any nonconformity is classified and must be corrected with evidence. The output is a stage 2 report with findings and a recommendation on certification. The step is done when all major nonconformities are closed and the certification body makes its decision.
Receive the certificate from the certification body
After review of the audit file and any corrective actions, the accredited certification body issues the certificate. The certificate names the organization, the scope and the standard edition, and it has a validity period tied to the three-year cycle. ISO does not certify organizations, so the certificate comes from the certification body, not from the implementation partner or the cloud provider. Customers can verify it through IAF CertSearch or by contacting the certification body. The output is a certificate and a published entry in the accreditation database. The step is done when the customer-facing scope and the certificate wording match.
Maintain the ISMS through annual surveillance
Within the three-year certification cycle, the certification body audits the ISMS at least once every calendar year. These surveillance audits sample the controls again, review changes to the product and cloud estate, check internal audits and management reviews, and follow up on previous findings. The organization runs its own internal audit, management review, risk review and corrective action process throughout the year. The output is a surveillance report each year and, at the end of the cycle, a recertification audit. The step is done when each surveillance audit closes without open major findings and the scope still reflects the product.
What A.5.23 asks SaaS companies to run for their cloud services
When a SaaS company runs its product on AWS or Azure, it is a cloud service customer under A.5.23. The control asks for defined processes covering how cloud services are acquired, how they are used, how they are managed and how the company exits them, all aligned with its own information security requirements. The cloud provider's ISO/IEC 27001 certificate covers the provider's infrastructure, not the company's configuration, so the company must show its own process for each phase.
- Acquisition: a documented approval step that records the security requirements, data location and the provider's shared responsibility terms before a new service or account is opened.
- Use: a baseline for accounts, identity federation, logging and encryption settings, checked against that baseline on a schedule.
- Management: a register of cloud accounts and services, with owners, and periodic reviews of provider certificates and reports that the company has actually read.
- Exit: a tested method for removing data, revoking access and closing accounts, including what happens to backups and logs.
An auditor usually asks for the cloud account register, the approval record for one recent service, the baseline configuration and a sample of review records. Confirm with your provider which reports it makes available and under what terms.
When the SaaS company is itself the cloud service provider to enterprise customers, A.5.23 still applies to the cloud services it buys, but the company also has to define how its own service is offered, configured and ended for each customer. Guidance in ISO/IEC 27017 and ISO/IEC 27018 helps here, and the company should decide early which of that guidance applies to its product and to what it does with personal data.
- Tenant model: a written description of how customer tenants are isolated, how administrators access them and how customer data is separated.
- Customer onboarding and offboarding: the steps that set up a tenant and the steps that return or delete its data at the end of a contract.
- Shared responsibility statement: a document that tells each enterprise buyer which controls the company operates and which the buyer must run.
- Tenant configuration evidence: exported policies, infrastructure definitions and access logs that show how a given tenant is set up.
Enterprise buyers often check the shared responsibility statement, the data return and deletion process and the subprocessor list. Confirm that the statement matches what the Statement of Applicability says the company does.
Many SaaS companies run production on one provider and keep parts of the platform, backups or customer deployments on another, or in their own data centers. A.5.23 applies to each cloud service separately, so the process must cover every provider, and the company must show that its requirements are applied the same way across them. Gaps usually appear where one team owns a provider that another team has forgotten.
- Single register: one inventory of every cloud and hosting service, including the owner, the data classes it holds and the provider's certificate scope.
- Common baseline: a minimum set of controls for identity, encryption, logging and backup that applies to each provider, with documented exceptions.
- Infrastructure as code: templates kept in version control, so that the same configuration can be reviewed and reproduced in each environment.
- Vendor reviews: a recurring review of each provider's certificate, its reports and any changes to its terms, recorded with the reviewer's name and date.
Before the audit, check that the register, baseline and review records agree with each other and with the Statement of Applicability. Ask the implementation partner to walk through one service end to end.
Using AWS or Azure certificates without being certified by association
Running on AWS or Azure does not make your company certified to ISO/IEC 27001:2022. AWS says customers are not automatically certified because they use AWS, although its own certification may make your certification easier to pursue when some or all of your IT runs on AWS. Microsoft takes a similar position: a customer pursuing its own certification for an implementation on in-scope Azure services can use Azure's certifications in its assessment, but it remains responsible for engaging an assessor to evaluate its implementation and its own controls and processes. The provider certificate covers the provider's infrastructure, facilities and operations. It does not cover your application code, your tenant configuration, your identity design, your change process or the people who run your product.
For a SaaS company, the practical split is that the provider's certificate supports the physical, environmental and much of the infrastructure-level evidence, while you must show how you use those services. Expect an assessor to ask for your cloud services processes under A.5.23, your configuration baselines for accounts, networks, storage and logging, your access reviews for the cloud console and production, and evidence that your own backups, encryption choices and monitoring work as described. Your shared responsibility matrix should state, service by service, which controls the provider operates and which ones your team owns. An enterprise buyer reading your Statement of Applicability will look for that boundary first.
Before you rely on a provider certificate in your scope, confirm three things. First, check the provider's current scope statement, because certificates list specific services, regions and dates, and a service you use may sit outside them. Second, verify the certificate itself through the certification body's published records rather than accepting a PDF from a sales contact. Third, ask your certification body how it will treat the provider's certificate in its audit plan, since the body, not the provider or your implementation partner, decides what evidence it accepts. Your implementation partner can prepare the mapping and collect the configuration evidence, but only the independent certification body issues your certificate.
How ISO/IEC 27017 and 27018 guidance applies to a SaaS product
ISO/IEC 27017 and 27018 add cloud-specific guidance on top of ISO/IEC 27002, which ISO/IEC 27001 Annex A points to. Neither can be certified to, but enterprise buyers often reference them, so a SaaS company should know which parts map to its own product and which belong to its cloud provider.
What ISO/IEC 27017:2026 covers
ISO/IEC 27017:2026 is the second edition of the cloud security guidance and replaces the 2015 edition. It adds cloud-specific guidance and additional controls to ISO/IEC 27002 for both cloud service customers and cloud service providers, across public, private and hybrid clouds. As a SaaS company you act as both: a customer of your IaaS provider and a provider to your own enterprise buyers. Check which guidance applies to each role before writing your Statement of Applicability.
Shared responsibility in the cloud
Cloud guidance asks you to split duties clearly between provider and customer. Your ISMS should record which controls your team operates in your tenant, such as identity configuration, logging and backups, and which are inherited from the provider's certified infrastructure. Ask your provider for its certificate scope and responsibility matrix, then test that your own configuration meets the controls you claim. An inherited control with no evidence of your own configuration will not satisfy an assessor.
What ISO/IEC 27018:2025 covers
ISO/IEC 27018:2025 gives guidelines for protecting personally identifiable information in public clouds where the cloud provider acts as a PII processor. It replaces the 2019 edition and builds on ISO/IEC 27002. If your product stores customer personal data in a public cloud, this guidance helps you define how your processing agreements, data return and deletion, and access to PII are handled. It does not replace your own privacy obligations under applicable law.
Guidance that cannot be certified
Neither ISO/IEC 27017 nor ISO/IEC 27002 can be certified to. Your certificate is to ISO/IEC 27001:2022, and the guidance documents inform how you design and evidence your controls. Buyers may ask you to show that your controls follow this guidance, so describe the mapping in your Statement of Applicability rather than claiming a certificate for the guidance itself. Confirm the exact wording your customer expects before you write it into contracts or questionnaire answers.
Using guidance in buyer questionnaires
Enterprise security questionnaires often reference cloud and PII guidance by number. Answer with the control you operate, the evidence you hold and the scope it covers, not with a general statement that you follow the guidance. Keep a short register that links each questionnaire theme to your Annex A controls, your architecture documents and the provider's certificates. This keeps answers consistent across buyers and avoids claims your evidence cannot support.
What an ISO 27001 SaaS certification costs and who gets paid
This table separates the cost of an ISO 27001 SaaS certification by who receives the money, whether the cost is one-time or recurring, and what drives it up. Read it as a checklist for building a quote, since no supplied figures exist for any line and the totals depend on your product footprint and scope. The main takeaway is that certification body fees are only one part of the budget, and the internal staff time and cloud tooling often matter as much.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Certification body audit, stage 1 and stage 2 | Accredited certification body | One-time for the initial certificate | Number of in-scope services, sites and people, plus the audit time the body calculates for your scope |
| Surveillance and recertification audits | Accredited certification body | Recurring within the three-year cycle | At least one audit each calendar year, with recertification at the end of the cycle; scope changes such as new product modules |
| Implementation partner work on systems and evidence | Implementation partner, under a written fixed scope | One-time, with optional retainer for upkeep | Number of services in scope, state of existing logging and access controls, and how much policy and evidence work is needed |
| Cloud infrastructure and security tooling | Cloud provider and tool vendors, or the hosting provider for self-hosted tools | Recurring | Log retention, number of environments, backup volume and any GRC or ticketing licenses you add |
| Internal staff time for roles, reviews and evidence | Your own payroll (no invoice, but a real cost) | Both: setup is one-time, reviews and management reviews recur | Headcount, number of product teams, and how many people hold roles under the ISMS |
| Gap remediation (technical and process) | Your engineers, or a partner if you buy remediation work | One-time for each gap, plus recurring fixes after audits | Maturity of access reviews, change management, vulnerability handling and supplier checks at the start |
| Cloud provider certificates and reports | Cloud provider (usually no fee to you for the reports) | Recurring access to current reports | Which provider services your product uses; confirm the terms of use and the in-scope services with the provider |
| Independent review and consultant advice on scope | Advisory firm or fractional security lead | Usually one-time, sometimes recurring | Whether you buy advice on scope, Statement of Applicability or customer questions, and how much is done in-house |
What makes SaaS ISO 27001 longer or more expensive
Audit time and cost for a SaaS company follow a few drivers: how much of the product and infrastructure sits in scope, how many people and cloud accounts the auditor must examine, how many third parties feed the ISMS, and how mature the evidence already is. Each driver can be narrowed or prepared for before the certification body quotes time.
Product and environment scope
Every product, region and environment you put inside the scope adds systems, owners and evidence to review. A single production SaaS platform with one staging environment is far smaller to audit than several products across three regions with separate development stacks. Before you commit, list each product, hosting region and environment, then decide which ones your enterprise customers actually rely on. Confirm with your certification body how it counts sites and environments, and document any exclusion with a reason in the Statement of Applicability, since clauses 4 to 10 cannot be dropped.
Headcount and roles in scope
Auditors sample people who build, operate and support the product, along with the staff who handle access, incidents and supplier contacts. Audit time reference material published by European Accreditation ties the calculation to the number of persons working within the scope, so a team that grows during the cycle can change the plan. Keep a current roster of in-scope staff, separate contractors from employees, and record role changes in your HR and access systems so the auditor can trace them.
Cloud accounts and environments
Each cloud account, Kubernetes cluster, database and identity tenant is a separate place where access, logging and change controls must be shown to work. Organizations that run many accounts for isolation often spend more audit time walking through them than teams with a small, well-described landing zone. Standardize account structure with infrastructure as code, keep a current inventory of accounts and owners, and confirm how your provider's certificates apply to services you have configured yourself. The provider's certificate covers its own infrastructure, not your implementation.
Third-party suppliers and subprocessors
Payment processors, support desks, monitoring vendors, email providers and offshore development firms all become part of your supplier control story. Each one needs a documented risk assessment, contract terms covering security and data handling, and periodic review, and auditors often sample several of them. Maintain a supplier register that lists the service, the data it touches, the contract owner and the last review date. Ask every supplier whether it holds its own certification, and keep a copy of the certificate and its scope with the register.
Maturity of CI/CD and logging evidence
Controls that run automatically in your pipeline, such as code review gates, dependency scanning and deployment approvals, produce evidence with little effort if the records are kept. Controls that depend on screenshots, manual exports or memory take longer to prove and invite more findings. Check whether your CI/CD system retains approval and build records for the audit period, whether centralized logs cover administrative and production access, and whether alerts create tickets you can trace. Gaps found during a readiness review are cheaper to close before stage 1 than during the certification audit.
Multi-site and remote audit approach
If your engineering team works from several offices or fully remotely, the certification body decides how many sites it must visit and which it can review remotely. The Global ACI multi-site guidance sets out how a sampling approach can reduce on-site visits, but the body must still justify its sample and time. Ask the certification body how it plans to audit cloud-hosted operations and remote staff, which evidence it will request in advance, and whether remote sessions are offered. Confirm these points in writing before accepting a quote.
Who owns the controls and who prepares the evidence
The SaaS company owns the information security management system, the scope, the risk decisions and every control in its Statement of Applicability. Management must set the policy, accept residual risk, assign owners and review performance. No partner can make those decisions on the company's behalf, and an assessor will ask management to show them doing so.
- Scope and risk decisions: Choosing which products, environments and services fall inside the ISMS, and accepting the risks in the risk treatment plan.
- Control ownership: Naming an accountable owner for each applicable Annex A control, including A.5.23 for the cloud services the product relies on.
- Internal review: Running internal audits and management reviews, and recording the nonconformities and corrective actions that follow.
- Day-to-day operation: Performing access reviews, onboarding and offboarding, change approvals and supplier reviews as recurring activities.
- Evidence ownership: Keeping the records that prove the controls operate, and producing them when the auditor asks.
Check that each control in the Statement of Applicability has a named internal owner who can explain it without the partner present.
An implementation partner such as DeployOpen prepares the technical and documentary groundwork that the company then operates. Work is usually agreed as a fixed scope in writing, and the partner's role ends at preparation. The partner does not decide controls for the company, does not sign off the Statement of Applicability, and does not issue audit reports or certificates.
- System hardening: Configuring self-hosted platforms, cloud accounts and build pipelines to the baseline the company has approved.
- Logging and monitoring: Setting up centralized logs, alerting and retention so that events relevant to the controls can be shown later.
- Backup and recovery: Implementing backup schedules and restore tests, with the results recorded as evidence.
- Documentation and evidence collection: Drafting procedures for company review and gathering configuration exports, tickets and logs into a repeatable evidence set.
- Readiness support: Walking through the controls with staff before the certification body arrives, so gaps appear internally first.
Ask any partner to put in writing which of these tasks it performs and which remain with your staff, and confirm that it will not sign or attest any control on your behalf.
An accredited certification body is the only party that audits the ISMS against ISO/IEC 27001:2022 and issues the certificate. ISO does not certify organizations, and the body must operate under accreditation to ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024 applied. The body's auditors must be independent of the advice the company received, which is why partner and auditor should be separate firms.
- Two-stage initial audit: Stage 1 reviews documentation and readiness, and stage 2 tests whether the controls operate in practice.
- Surveillance and recertification: Audits recur through a three-year certification cycle, with at least one audit in every calendar year.
- Nonconformities: Findings are raised formally, and the company must answer them with corrective actions that the body then verifies.
- Certificate scope: The body states which products, sites and services the certificate covers, which matters for SaaS buyers reading the certificate.
- Public verification: Buyers can check the certificate in the IAF CertSearch database.
Before you engage a body, confirm its accreditation status and that it has no advisory relationship with the partner you hired.
Most ISO 27001 work sits across all three parties, and the risk is in the handoffs. A partner may configure a logging stack that the company never reviews, or a company may assume the audit body will find gaps that it should have fixed. A simple split of who prepares, who decides and who verifies prevents both problems.
- Prepare: The partner builds the system, the scripts and the first evidence exports.
- Decide: The company approves the policy, the risk treatment and every Statement of Applicability entry.
- Operate: The company runs recurring reviews and keeps records as the controls work over time.
- Verify: The certification body samples evidence and tests operation, then decides on certification.
- Hand over: Agree in writing who keeps the runbooks, configuration code and evidence repository after the engagement ends.
An illustrative check: if a control's evidence is a screenshot the partner made during setup, the company should be able to show the same control operating last month without the partner.
What delays SaaS ISO 27001 projects and how to avoid it
Most SaaS ISO 27001 projects slow down for the same few reasons: the team has not agreed where the product boundary sits, provider certificates are assumed to cover more than they do, and evidence is collected at the end instead of during operation. Each card names one delay and the check that prevents it before the audit window opens.
Unclear product boundary
If the team cannot say which services, environments, repositories, support tools and staff roles belong to the product, the scope statement changes during stage 1 and the Statement of Applicability is rewritten more than once. Write the boundary as a diagram listing production, staging, build pipelines, support access and corporate tools, then mark each as in or out. Ask the certification body early whether its scope wording matches what enterprise buyers will read on the certificate.
Provider certificates taken at face value
A cloud provider's ISO/IEC 27001:2022 certificate covers the provider's own controls for the services in its scope. It does not certify the SaaS company's configuration, access model or application code. Map each in-scope cloud service to the provider's certificate and list which controls remain the company's responsibility, then ask the auditor to confirm that approach. Check that the services you use appear in the provider's certificate scope before you rely on it.
Missing supplier reviews
Third-party services that touch customer data, such as hosting, logging, email, payments and support tooling, need documented reviews before the auditor samples them. Teams often hold contracts but no record of security review, data location or exit steps. Build a supplier register that records the service, the data it handles, the review date, the contractual security terms and the exit plan, and review each entry at least once before the audit.
Undocumented change management
Auditors test whether production changes follow a repeatable path with review and approval. If pull requests, deployments and emergency fixes each follow different habits, sampling fails and the team spends weeks reconstructing history. Define one change procedure covering code review, testing, approval, deployment and rollback, and confirm that the pipeline records it automatically. Document how emergency changes are reviewed after the fact.
Evidence gathered too late
Controls that operate for weeks without records cannot be shown to have operated during the audit period. Access reviews, vulnerability scans, training completion, backup restore tests and incident drills all leave dated proof only when they are run and kept. Start an evidence calendar on day one, assign each recurring control an owner and a storage location, and sample a few items each month to confirm they are complete before the auditor asks.
Questions SaaS buyers ask before hiring help for ISO 27001
How long does ISO 27001 take for a SaaS company, and what drives the timeline?
There is no fixed duration, and anyone quoting one without seeing your environment should be questioned. The timeline is driven by how many services and systems fall inside scope, how mature your existing security practices are, how many people hold roles that need evidence, and how quickly your team can produce records. Certification itself follows a two-stage initial audit, which the certification body plans and runs. Ask any partner to show how they break the work into phases, what they need from you in each phase, and which dates depend on the certification body's availability. Your certification body's audit programme will set the audit calendar, so confirm it early.
Can a small SaaS team run ISO 27001 without outside help?
Yes, many small teams do, but the work needs a named owner with time set aside for it. The standard expects top management to direct the management system, and it expects a documented risk assessment, a Statement of Applicability, internal audits and management review. Engineers will carry much of the technical evidence, such as access reviews, change records and logging. Decide early who owns the ISMS, how much of their week it takes, and which tasks you will hand to a partner. Outside help is most useful for scoping, drafting the Statement of Applicability and preparing evidence, while your organization keeps ownership of every control.
What does ISO 27001 need from engineering and leadership?
Engineering supplies most of the technical evidence and leadership supplies the decisions and oversight. Engineering typically maintains asset inventories, configuration baselines, change and deployment records, vulnerability management, backup tests, logging and secure development practices. Leadership must approve the policies, set risk appetite, accept residual risks, sponsor the programme and attend management review. Before you start, agree on the tools that will hold the evidence, who reviews access each quarter, and how incidents are recorded. Gaps in these habits take longer to fix than the paperwork itself, so assess them honestly before choosing a timeline.
Are AWS or Azure certificates enough for our SaaS ISO 27001 certification?
No. Using a cloud provider's certificate does not certify you. AWS states that customers are not automatically certified because they use AWS, but its certification may make your own certification easier. Microsoft says a customer can use Azure's certifications in its assessment for an implementation on in-scope services, yet the customer must still engage an assessor to evaluate its own implementation, controls and processes. Your scope must cover your application, operations and people, and the cloud provider's controls only cover the infrastructure layer. Read the provider's responsibility split and map it to your own controls, including control A.5.23 on cloud services.
Does the certificate cover the whole company or only the product?
The certificate covers the scope you define, and the scope can be narrowed by organization, location or service. For a SaaS company, the most common choice is the product and the teams and infrastructure that build and run it, but the scope must still meet the management system requirements in clauses 4 to 10. You cannot exclude a clause to make the scope smaller. Buyers will check the certificate's scope statement against the services they buy, so an unclear scope invites questions. Ask your certification body to confirm the scope wording before the stage 1 audit, and check whether shared corporate functions fall inside or outside it.
How does an implementation partner differ from a certification body?
An implementation partner prepares your systems, controls and evidence, while a certification body independently audits them and issues the certificate. Partners such as DeployOpen plan, configure, document and support self-hosted platforms inside your environment, and they do not issue audit reports or certificates. The certification body must be accredited and must be independent of the work it audits, so do not use the same firm to design your controls and to certify them. Before hiring anyone, confirm in writing what the partner delivers, what stays with your team, and which parties hold which decisions. Check certificates through the IAF CertSearch database, which ISO lists for verification.
What recurs after the first ISO 27001 certificate is issued?
The certificate lasts for a three-year cycle, and the certification body must carry out at least one audit in every calendar year of that cycle. Those audits are surveillance or recertification audits, and each one checks whether the management system still works. Your team will keep running internal audits, management reviews, risk reassessments, access reviews and corrective actions throughout the cycle. Ask any partner whether ongoing support is included or offered as a separate retainer, and ask for the work it covers. Budget for the recurring effort and the audit fees, not just the first certification.
How DeployOpen scopes and prepares SaaS systems and evidence for ISO 27001
DeployOpen works on the infrastructure and tooling behind a SaaS product, inside the client's own cloud accounts or data centers. We prepare systems, controls and evidence for an assessment, while the organization keeps ownership of its ISMS and an independent certification body issues any certificate.
How we scope
- Agree a written scope that names the product, environments, hosting accounts and teams covered by the ISMS.
- Map which cloud services sit in scope under A.5.23 and which provider certificates the client will rely on.
- Confirm with the client's certification body how it will treat the chosen boundary before build work starts.
How we build
- Deploy and harden self-hosted open-source platforms for access, logging, ticketing, backups and vulnerability tracking.
- Configure infrastructure as code so that change records and configuration baselines can be produced as evidence.
- Run security testing of the in-scope application and APIs and record findings against the relevant Annex A controls.
How we hand over
- Document the systems, configurations and procedures in a form the client's own staff and assessor can read.
- Provide an evidence map linking each in-scope control to the logs, records and tests that show it operates.
- Deliver the written scope outcomes, configuration documentation and runbooks so the client keeps control after the engagement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement ends.
- Assist with assessor questions about the technical evidence, while the client remains responsible for its ISMS decisions.
- Confirm the support terms, response expectations and retainer scope in writing before any ongoing work starts.
