ISO 27001 for software companies looks different from the version most people picture. The image is usually policies, binders and a locked server room. For a company whose product is code, the majority of the standard lands inside the delivery process instead, in decisions engineers make every week.
That matters in two directions. If you are buying software, it tells you which questions actually test whether a supplier's certificate means anything. If you are a software company considering certification, it tells you how much of the work is engineering rather than documentation.
What follows is the six areas where the standard bites hardest in a development organisation, and for each one the evidence a client can reasonably ask to see.
What ISO 27001 for software companies actually requires
The standard certifies an Information Security Management System, which sounds administrative until you look at where the controls have to operate. In a consultancy the answer is offices and laptops. In a software company it is repositories, build pipelines, environments and the people who hold credentials to all three.
So the same certificate means something quite different depending on what the organisation does. ISO 27001 for software companies therefore concentrates in places a generic audit summary never mentions. Two columns below set out where the weight sits for a development team.
This distinction explains a pattern buyers notice once they know to look for it. A consultancy and a development house can hold certificates that read almost identically on the front page, while the underlying audits examined completely different things. One looked at laptops, training records and a risk register. The other looked at all of that plus the pipeline that ships code to production.
Six areas where ISO 27001 for software companies reaches delivery
None of these are exotic. Plenty of teams already work this way, because the practices predate the standard and exist for engineering reasons rather than compliance ones. What ISO 27001 for software companies adds is not the practice itself but an external auditor who checks it, and returns every year.
Offboarding deserves particular attention, since it is where certified and uncertified organisations diverge most visibly. Granting access is easy to do well because someone is waiting for it. Removing access the week a developer rolls off a project has nobody pushing for it, which is exactly why an auditor asks.
Dependency management has become the other reliable separator, largely because of how software is built now. A modern application carries hundreds of third-party components, and each one is a route into your systems if nobody tracks it. A team that can produce an accurate inventory on request is a team that already knows what it ships.
What evidence to request from an ISO 27001 certified software supplier
Certification tells you an auditor was satisfied. It does not tell you what they examined, which is why three specific requests are worth more than a twenty-page questionnaire.
Why the scope statement decides everything
Two certificates can carry the same standard, the same accredited body and the same logo while covering entirely different activities. One reads "information security management for the corporate head office". Another reads "design, development, delivery, maintenance and support of software and information technology solutions".
Only the second tells you the engineers writing your code work inside the certified system. Reading that paragraph takes thirty seconds and settles more about ISO 27001 for software companies than any questionnaire will, yet it is the part almost nobody opens.
The scope also tells you whether external people are covered. If a supplier places engineers inside your organisation, or works through partner agencies, the certificate is only useful when those arrangements sit within the certified system. A scope that stops at permanent employees leaves out precisely the arrangement you are buying.
Caixa Mágica Software holds certificate 26ISMS-1252 under ISO/IEC 27001:2022, with a scope covering design, development, delivery, maintenance and support of software and IT solutions, including nearshore and team augmentation services. You can read what our certification covers or verify it directly in the IAF CertSearch database.
When ISO 27001 for software companies is worth pursuing
For a software company weighing certification, the honest calculation is commercial rather than technical. If your clients are essential or important entities under NIS2, financial entities under DORA, or public administration, the requirement is already arriving through their contracts and questionnaires. Certifying once costs less than answering the same questions twenty times a year.
If none of your clients are regulated, the case for ISO 27001 for software companies is weaker and the work is real. Expect the documentation effort to be smaller than feared and the process discipline to be larger, particularly around access reviews and evidence retention.
One thing worth deciding before starting: how wide the scope will be. A narrow scope is cheaper to achieve and considerably less useful, because buyers who know how to read a certificate will notice. Covering the delivery chain end to end costs more in preparation and answers far more questions later.
Frequently asked questions
Five questions come up whenever certification and software delivery meet, so the answers are collected here.
What does ISO 27001 require from a software company?
Does ISO 27001 certify the software a company builds?
How long does ISO 27001 certification take for a software company?
What evidence can a client ask an ISO 27001 certified supplier for?
Is ISO 27001 enough to satisfy NIS2 or DORA?
