Does ISO 27001 apply to a company that ships self-hosted software?
Yes, ISO 27001 applies to a vendor that ships self-hosted software, but the certificate covers the vendor's own information security management system, not the customer's runtime. The vendor can certify a scope that includes its development, support and internal operations. Only an accredited certification body can issue that certificate after an audit, and the vendor cannot certify the environments its customers build and run the product in. What moves the scope is a short list of facts about the business. Ask whether the vendor hosts any service for customers, such as a license server, a telemetry endpoint or a managed update portal. Ask whether support staff receive customer data, logs, configuration files or database extracts during troubleshooting, and where that data is stored. Ask whether the vendor operates an update channel that customers pull from, because the signing keys, build pipeline and distribution servers then fall inside the information assets the ISMS must protect. Each yes adds components to the scope, and each no is a reason to narrow it. Scope can be narrowed by organization, location or service, but clause 1 of ISO/IEC 27001:2022 states that excluding any requirement in clauses 4 to 10 is not acceptable for a conformity claim. A vendor may therefore leave out a hosted product line or a business unit, but it cannot skip the context, leadership, planning, support, operation or improvement clauses. Confirm the exact wording of the scope statement with the certification body before the stage 1 audit, because the scope written there is the one customers will read on the certificate.
Which secure development controls an assessor will test
A.8.25 Secure development life cycle asks the organization to establish rules for the secure development of software and systems and to apply them. An assessor first checks that the rules exist in writing, then checks that the development team actually followed them. For a vendor shipping software that customers run themselves, the rules must cover every stage that produces a release, including the work done by any outsourced developers.
- Written secure development policy: a document that names the stages, roles and mandatory checks, approved by someone with authority over engineering.
- Definition of done: a checklist attached to each work item that shows which security steps were completed before merge or release.
- Release gate records: tickets, pull request approvals or pipeline results that show the gate was passed for specific versions.
- Exception register: dated approvals for any skipped step, with a named owner and a closure date.
- Review cycle: evidence that the rules were reviewed after incidents, tooling changes or major releases.
Confirm with your auditor which sample of releases they will trace back to the written rules, and make sure your tooling retains that history for the full audit period.
A.8.26 Application security requirements and A.8.27 Secure system architecture and engineering principles ask that security needs be identified before build and that the architecture reflects documented engineering principles. Assessors look for records made at the start of a feature or product change, not retrofitted reports. For self-hosted software, the design must also account for the customer's deployment, such as default configurations, secrets handling and upgrade paths that the customer will operate.
- Security requirements per feature: records of authentication, authorization, data handling and logging needs for a specific change.
- Threat model records: dated models for significant components, with identified threats, owners and the decisions taken.
- Architecture principles document: the engineering principles the team committed to, such as least privilege and secure defaults, with examples of their use.
- Design review minutes: who reviewed the design, what was challenged and how the outcome was recorded.
- Deployment hardening guidance: the secure configuration expected of the customer, linked to the requirements it addresses.
Check that each sampled feature traces from its requirement to its design decision and then to its test, because assessors often follow that thread.
A.8.28 Secure coding is one of the 11 controls new in the 2022 revision of Annex A, with no counterpart in the 2013 edition. It asks that secure coding principles be applied to software development. Assessors expect the organization to show how developers were guided and how code was checked before it was merged, so the evidence is mostly process records and review artifacts rather than a single report.
- Coding standards: language or framework guidelines the team adopted, with the date and owner of each version.
- Peer code review records: pull request approvals showing a reviewer other than the author checked security-relevant changes.
- Static analysis results: scan outputs for sampled releases, with triage decisions for each finding that was not fixed.
- Secure coding training records: attendance or completion for developers, linked to the topics covered.
- Dependency checks: records showing third-party components were reviewed for known vulnerabilities before inclusion.
Ask your tooling vendor and your own team to confirm which of these records your pipeline produces automatically. Do not assume a scanner's output alone satisfies the control without the triage trail.
A.8.29 Security testing in development and acceptance asks that security testing be defined and performed during development and before systems are accepted. For vendors, the testing evidence must tie to specific release versions, because customers deploy versions, not intentions. Assessors sample a release, then look for the test plan, the executed tests and the record of what was fixed before shipping.
- Security test plan: the test types used, such as dynamic testing or penetration testing, and the scope each covers.
- Test reports per release: results tied to a version identifier, including failed tests and their resolution.
- Acceptance criteria: the security conditions a release must meet before customers receive it.
- Penetration test reports: independent test results, with remediation status and retest evidence.
- Defect records: tickets for security findings, showing severity, fix and verification.
Confirm that your release process can reproduce the test evidence for any version a customer still runs, since assessors may ask about older releases within the audit period.
How outsourced development falls under A.8.30
When contractors or offshore teams write product code, A.8.30 Outsourced development still applies to you as the vendor. The organization must direct, monitor and review that work, so the controls below show how to keep the outsourced code inside your own ISMS.
Contract security clauses
The contract is the first place A.8.30 is met. Require the contractor to follow your secure development rules (A.8.25), to report security defects promptly, to return or destroy source code and credentials at exit, and to accept audit of its practices. Confirm which subcontractors may touch your code and that the contract flows these obligations down to them. Check that supplier terms align with A.5.20 Addressing information security within supplier agreements, so the same clauses appear in every engagement.
Repository access rules
Contractors should reach your source code only through named, individually issued accounts with multi-factor authentication and the minimum branch permissions their task needs. Remove access when a sprint or engagement ends, and review the access list on a fixed schedule. Keep contractor machines and build credentials out of the default developer pool. Ask your team to show, from the repository's own logs, who pushed which change and when.
Review gates before merge
Every change written by a contractor should pass a review by a staff member of your company before it reaches a protected branch. The reviewer should not be the same person who wrote the change. Automated checks such as static analysis, dependency scanning and secret detection can run as required status checks, so unreviewed or failing code cannot merge. Record the approval in the pull request so an assessor can trace it.
Acceptance testing of delivered work
Before outsourced code is accepted into a release, your own staff should test it against the requirements and security criteria set for the feature. Acceptance testing covers functional behavior, security test results from A.8.29 Security testing in development and acceptance, and any open findings. Keep signed acceptance records linked to the release, and do not accept a delivery with unresolved high-severity issues without a recorded risk decision.
Periodic review of the supplier
Monitoring does not end at delivery. Review each development supplier on a set schedule: confirm that its staff still meet your training and background requirements, that its access is current, that it has reported defects and incidents, and that the contract still reflects the work. Record the findings and the actions taken. This periodic review gives you the monitoring evidence A.8.30 expects and feeds into the supplier controls in A.5.22.
How NIS2 supply chain rules relate to ISO 27001
NIS2 is binding EU law, while ISO/IEC 27001:2022 is a voluntary international standard, and NIS2 does not require ISO 27001 certification. The distinction matters for a self-hosted software vendor because the obligation sits with your customers, not with you. Directive (EU) 2022/2555 is enforced by national authorities that can impose fines, and it requires essential and important entities to manage the security of their supply chain, including the relationships with the suppliers and service providers they depend on. A certificate from an accredited certification body can help you answer those questions, but it does not discharge anyone's legal duty, and a regulator will not accept a certificate as a substitute for the risk-management measures a customer must run.
Expect the duties to flow down to you. A bank, energy operator or hospital group subject to NIS2 will typically ask how you assess your own security, how you handle vulnerabilities in the software they run, how you communicate incidents and how you secure your development and support access. Those questions map closely to the supplier and outsourced development controls in Annex A. Before you choose a response, ask each customer which NIS2 measures they have mapped to supplier obligations and whether they expect a certificate, an attestation, or answers to their own questionnaire. Their answer decides how much of the ISMS evidence you should package for them.
For the technical detail, read Commission Implementing Regulation (EU) 2024/2690, which sets out specific technical and methodological requirements for the entities it covers. The ENISA NIS2 technical implementation guidance includes a mapping table that links its measures to other frameworks, and the mapping is a useful starting point for a crosswalk. Treat it as a reference to check against your own Statement of Applicability, not as a finished answer. Confirm with your customers' compliance teams, and where needed with a qualified adviser, which article and measure applies to each obligation before you claim coverage.
How the certification process runs for a software vendor
The sequence moves from defining what the ISMS covers to an accredited certification body issuing a certificate, then keeps that certificate alive through audits across a three-year cycle. Each phase produces a document or record that the next phase depends on.
Define scope and run a gap assessment
The vendor decides which products, development teams, support functions and internal systems fall inside the ISMS, and which customer-hosted deployments are excluded because the vendor does not operate them. Clauses 4 to 10 cannot be dropped from the scope, so the boundary is drawn around products, locations or services, not around requirements. A gap assessment then compares current practice against each clause and each Annex A control. The output is a scope statement and a gap list with an owner for every item.
Assess risk and write the Statement of Applicability
The vendor sets a risk assessment method, identifies risks to the confidentiality, integrity and availability of information in the scope, and decides how each risk will be treated. Risks around release pipelines, customer-side updates, support access to customer environments and outsourced developers usually need explicit treatment. The Statement of Applicability then records every Annex A control, whether it applies, and why, with a link to the implementing evidence. The output is an approved risk register and a signed Statement of Applicability.
Implement controls and collect evidence
Control owners put the decided measures in place. For a software vendor this typically covers the secure development life cycle under A.8.25, secure coding under A.8.28, security testing under A.8.29, outsourced development under A.8.30 and supplier management under A.5.19 to A.5.23. Each control should leave records such as code review logs, test reports, supplier assessments and change tickets, gathered on a routine basis rather than assembled for the audit. The output is an evidence folder per control that shows the control operated over time.
Run an internal audit and management review
Someone independent of the control owners checks the ISMS against the standard, the Statement of Applicability and the organization's own procedures. Findings are logged as nonconformities or observations, and corrective actions are assigned with due dates. Top management then reviews the ISMS status, risk treatment progress, audit results and improvement opportunities. The output is an internal audit report, a corrective action log and minutes of the management review that show leadership reviewed the system.
Complete the stage 1 documentation review
The accredited certification body reviews the documented ISMS, including the scope, policies, risk assessment, Statement of Applicability and internal audit and management review records. The purpose is to confirm the system is designed to meet the standard and that the organization is ready for a detailed test. Gaps found here are typically reported back for correction before the next stage. The output is a stage 1 report that lists any areas to resolve before stage 2.
Pass the stage 2 implementation audit
The certification body tests whether the ISMS works in practice. Auditors sample evidence for controls across development, release, support and supplier management, interview staff and check that the controls match the Statement of Applicability. Any nonconformity must be corrected and the correction verified before a certificate is issued. Ask the certification body for an audit time estimate based on its own rules, since the time depends on the scope and headcount. The output is a stage 2 report and, once nonconformities are closed, a certification decision.
Maintain the certificate through the three-year cycle
The certificate covers a three-year cycle. Under the rules for accredited certification bodies, at least one audit happens in each calendar year, either a surveillance audit or the recertification audit at the end of the cycle. Between audits, the vendor keeps running internal audits, management reviews, risk reviews and evidence collection, and reports changes in scope or product architecture to the certification body. The output is a continuing ISMS and an up-to-date certificate verified in the IAF CertSearch database.
Who owns each control, who prepares evidence, and who certifies
This table shows, for each key ISMS activity in a self-hosted software vendor's programme, who makes the decision, who prepares the supporting evidence and who issues the certificate. Read each row left to right: the vendor always owns the decision, the implementation partner prepares systems and records, and only the independent certification body issues the certificate. DeployOpen prepares systems and evidence and does not issue reports or certificates.
| Activity | Vendor owns | Implementation partner prepares | Independent certification body issues |
|---|---|---|---|
| ISMS scope decision | Chooses which products, development teams, support functions and sites are in scope, and signs off the Statement of Applicability | Maps product lines, build pipelines and support tooling to scope boundaries and documents the rationale | Reviews the scope in stage 1 and confirms it on the certificate |
| Risk assessment and treatment | Accepts residual risk and approves the risk treatment plan | Prepares the risk register, asset inventory and draft treatment options for each product line | Samples the risk process and tests whether treatment matches the documented risks |
| Secure development rules (A.8.25) | Approves the secure development life cycle policy and the rules developers follow | Drafts the rules, wires them into code review, CI pipelines and release gates, and captures the records | Samples pipeline logs, review records and release approvals to confirm the rules are applied |
| Secure coding and security testing (A.8.28, A.8.29) | Sets acceptance criteria for releases and owns exceptions | Configures static analysis, dependency checks and security test stages, and preserves outputs per build | Tests whether findings are triaged, tracked and closed before release |
| Outsourced development oversight (A.8.30) | Decides which work is outsourced and remains accountable for the code shipped | Sets up access, review and acceptance steps for contractor code and records the monitoring | Checks that direction, monitoring and review of contractor activity is performed and recorded |
| Supplier contracts (A.5.19, A.5.20) | Negotiates and signs supplier terms, including security and breach obligations | Maintains the supplier register, security questionnaires and contract clause checklist | Confirms the supplier controls exist and are followed in practice |
| Customer-imposed supplier controls | Answers customer audits, assessments and contractual security demands | Prepares the evidence pack, control mappings and test records customers request | Does not assess customer requirements; it only confirms the vendor's own ISMS |
| Certificate issuance | Corrects nonconformities and maintains the ISMS between audits | Prepares readiness checks and internal audit records before the audit | Issues the certificate after accredited audit, and runs surveillance and recertification audits |
What delays software vendor projects and how to avoid it
Most delays in an ISO 27001 project for a self-hosted software vendor trace back to a few early decisions: where the scope stops, who operates what after delivery, and whether release evidence exists. Each card below names one of these gaps, why it matters to the assessor and to the customers reading the certificate, and the check that prevents it.
Scope that leaves out the pipeline
Teams often scope the ISMS to the product and forget the build system, source repositories, artifact signing keys and release tooling that produce what customers install. Clause 1 does not allow dropping requirements from clauses 4 to 10, and the secure development controls only make sense if the pipeline sits inside the boundary. Before stage 1, map every system that touches code from commit to signed package and decide, in writing, which ones are in scope.
Unclear customer-operated boundaries
A self-hosted product runs in systems the vendor does not control, so the Statement of Applicability must say which controls the customer operates and which the vendor operates. Vague wording here invites assessor findings and customer questions about what the certificate actually covers. Write a responsibility matrix for installation, patching, backup, access and logging, and reference it from the relevant Annex A controls.
No evidence of review and testing per release
Assessors look for proof that each release went through code review and security testing, not just a policy saying it should. Records such as merge approvals, pipeline test results and documented findings with their resolution are the usual evidence for the secure coding and security testing controls. Confirm that your tooling retains these records for every release and that they can be exported for the auditor's sample.
Undocumented contractors in development
Outsourced development is common in product companies, and the outsourced development control asks you to direct, monitor and review that work. Contractors who commit code without contracts, security requirements, or access reviews create gaps the assessor will sample. Keep a register of every external developer and vendor with the agreement, access granted and review date, and make sure those agreements carry the same security requirements as your own staff.
Questionnaires that exceed the certificate
A certificate does not answer every question in a customer's security questionnaire, especially those about hosting details, sub-processors or product-specific hardening that sit outside the certified scope. Map recurring questions to the Statement of Applicability before answering, and mark which items the certificate covers and which need separate evidence. Confirm with each customer what their procurement team will accept as proof before promising more than the scope supports.
Questions software vendors ask before starting ISO 27001
Are customer-run deployments of our software in scope for ISO 27001?
Usually the software itself is not what gets certified, because the certified scope is the set of activities, products and services your organization runs under its own control. For a vendor that ships software customers operate, the ISMS normally covers your development, release, support and update activities, and the controls that protect your source code, build pipeline, vulnerability handling and customer data you hold. What runs in a customer's environment is generally outside your operational control, so it is described through your responsibilities, documentation and support model rather than as a certified production system. Clause 1 does not allow you to exclude any requirement in clauses 4 to 10 to make a conformity claim, but the scope itself can be narrowed by service or location. Confirm the exact boundary with your certification body before you write the scope statement.
Can we get certified without hosting anything ourselves?
Yes, a vendor that hosts nothing can still hold a certificate, because ISO 27001 applies to how an organization manages information security, not to where its customers run the product. Your ISMS must still cover risk assessment, the Statement of Applicability, leadership duties, internal audit and management review. The Annex A controls you select will reflect your real activities, such as secure development, access to source repositories, supplier management and handling of customer support data. Where a control does not apply, the Statement of Applicability must say why. Expect your auditor to test whether your documented processes match what engineers actually do. Ask the certification body how it counts people and sites in audit time, since a development-only company is scoped differently from a hosting provider.
What do the secure development controls require from our engineering team?
A.8.25 asks you to establish rules for the secure development of software and systems and to apply them. In practice the closely related controls expect written requirements for security in each project (A.8.26), secure architecture and engineering principles (A.8.27), secure coding practice (A.8.28) and security testing during development and acceptance (A.8.29). A.8.28 Secure coding is one of the 11 controls that are new in the 2022 revision of Annex A. Auditors typically ask to see a defined development life cycle, code review records, testing results from pipelines, and how security defects are tracked to closure. Your engineers need to follow these rules consistently, so the evidence is usually the normal output of your tools: pull request reviews, static analysis results, dependency scans and release sign-off. The cost is mainly internal time to define and maintain the rules, plus tooling. Ask an implementer to show how these records are produced by your existing pipeline before deciding on new tools.
How do we handle contractors and outsourced developers under ISO 27001?
A.8.30 Outsourced development asks your organization to direct, monitor and review the activities related to outsourced system development, so using a contractor does not transfer responsibility for their work. You need to define what the contractor may access, require them to follow your secure development rules, review their deliverables and record that review. Contract terms belong under A.5.20, Addressing information security within supplier agreements, and supplier risk is covered by A.5.19, which asks for processes to manage risks from suppliers' products or services. Monitoring and changes to supplier services fall under A.5.22. Keep a register of contractors with access to code and customer data, and make sure offboarding removes their repository and environment access. Your auditor will look for evidence that you actually reviewed the outsourced work, not just a clause in a contract.
Does ISO 27001 satisfy NIS2 supply chain requirements for our customers?
No. NIS2 is EU law, enforced by national authorities with fines, while ISO/IEC 27001:2022 is a voluntary international standard. NIS2 does not require ISO 27001 certification. A certificate can, however, provide useful evidence when your customers, who may be essential or important entities under NIS2, assess their supply chain security. Those customers must manage risks from their suppliers under the Article 21 risk-management measures, and the technical requirements in Implementing Regulation (EU) 2024/2690 apply to certain digital providers. Mapping work between the two frameworks is available from ENISA's implementation guidance, but the mapping should be checked against your own obligations. Ask your customers which evidence they need and whether a certificate, a questionnaire response or a contract clause will satisfy them.
What does ISO 27001 need from our internal team, and how much time?
You need a named owner for the ISMS, top management involvement under clause 5, people who run the controls day to day, and staff who can perform internal audits. The main recurring effort is keeping records current: access reviews, vulnerability handling, supplier reviews, training records and management review minutes. Effort depends on how many systems, repositories and suppliers are in scope, how mature your engineering processes already are, and how many people you have to assign. Engineers who already run code review and CI pipelines will need less extra work than a team relying on manual release steps. Ask any consultant to estimate effort from your scope and tool inventory in writing, and ask the certification body how its audit days are calculated, since its method is set by ISO/IEC 17021-1 and ISO/IEC 27006-1.
Can a partner build the ISMS and controls for us, and what stays with us?
A partner such as DeployOpen can plan, implement, integrate, harden and document the systems and controls that produce ISO 27001 evidence, and can prepare the records an auditor will review. Under ISO 27001 the organization still owns its controls, the risk decisions, the Statement of Applicability and the management commitments. Only an independent certification body can audit and certify you. DeployOpen does not issue audit reports or certificates. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support or testing can be arranged as a retainer. Ask any implementer to state in writing which tasks it performs, which remain yours, and how it stays independent of the certification body you choose.
What to check before hiring a certification body or implementation partner
Before you sign with anyone, confirm that the certification body is accredited for ISMS certification and that it works to ISO/IEC 17021-1 together with ISO/IEC 27006-1. Ask for its accreditation scope in writing and check it against the accreditor's listing. Once a certificate exists, verify it yourself in the IAF CertSearch database, which ISO still points to for accredited certificates, rather than relying on a PDF supplied by the vendor. For a self-hosted software vendor, also confirm that the certification body's scope covers the development, release and support activities you actually run, not only the office IT environment.
Keep the roles separate. An implementation partner prepares your ISMS, configures the tooling that produces evidence, writes procedures and trains your staff. Your organization still owns the controls, the Statement of Applicability and the decisions behind them. The auditor must be independent of that preparation work, so the firm that designed your secure development pipeline should not also be the one that certifies it. If one firm offers both services, ask how it manages that conflict and who signs off each deliverable. The auditor's job is to test your system and issue, or withhold, the certificate.
Before signing either contract, ask for a written scope that names the products, the development and support teams, the release channels, the customer-hosted deployment models and the excluded activities. Ask for a deliverables list with an acceptance step for each item, and for a written statement of how evidence will be handed over: which repositories, ticketing systems, build logs and policy documents you will own, in what format, and whether you can keep working with them after the engagement ends. Ask which items are fixed in the agreement and which are charged by the day, so that changes to scope are priced before they happen.
How DeployOpen prepares a self-hosted software vendor's ISMS evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside client infrastructure. For software vendors, we help prepare the systems, controls and evidence that an ISO 27001 assessment will examine, while the organization owns its controls and an independent certification body issues any certificate.
How we scope
- We agree in writing which products, development teams, support processes and supplier relationships fall inside the ISMS boundary.
- We document which customer-deployed components the vendor controls and which remain the customer's responsibility.
- Scope, deliverables and timelines are fixed in writing before work starts, and any quote follows from that written scope.
How we build
- We help define secure development rules that map to A.8.25 through A.8.29, using tooling inside your own build pipeline.
- We set up outsourced development oversight under A.8.30, including access, review and acceptance records for contractor work.
- We configure supplier and cloud records for A.5.19 to A.5.23 so each supplier relationship produces reviewable evidence.
How we hand over
- You receive documented procedures, configuration records and evidence collection steps that your staff can run after the engagement ends.
- We prepare an evidence index that shows, for each relevant control, where the artifact lives and who owns it.
- We walk your team through the handover so the ISMS can be maintained and presented to an independent auditor without us.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial engagement.
- Retainers can cover evidence refresh before surveillance or recertification audits, ahead of the three-year cycle.
- Confirm with your certification body which evidence formats and sampling approach it expects before the retainer scope is set.
