iso27001partnersRunning an ISMS in the tools you already have
“Documented information required by the [information security] management system and by this document shall be controlled to ensure: a) it is available and suitable for use, where and when it is needed; b) it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity).” — the harmonized-structure text of clause 7.5.3, which ISO/IEC 27001 applies. Nothing in it names a product, and no certification body can require you to buy one.
“Can we do this in Confluence?” is a question technical teams ask before starting. The honest answer is yes, along with Jira, Microsoft 365, Azure DevOps, GitHub, and a well-kept shared drive. What differs is which controls each one evidences without extra effort and where each one leaves a hole.
What the standard actually asks of your tooling
| Clause | What it requires | What satisfies it |
|---|---|---|
| 7.5.2 Creating and updating | “identification and description”, “format … and media”, “review and approval for suitability and adequacy” | Any tool with version history and a recorded approver. SharePoint, Confluence, Google Docs and Git all qualify. |
| 7.5.3 Control of documented information | “available and suitable for use, where and when it is needed”; “adequately protected”; distribution, access, storage, “control of changes (e.g. version control)”, “retention and disposition” | The word that catches people is controlled: one current version, and permissions that mean not everyone can change it. |
| 9.2 Internal audit | An audit programme; “objectives, criteria and scope for each audit”; results “reported to relevant managers” | A ticket per finding with an owner and a closure date is better evidence than a report nobody opened. |
| 9.3 Management review | Specified inputs, documented results | Minutes. There is no tooling answer to this one — it is a meeting, and the evidence is a record of it. |
| 10.2 Nonconformity and corrective action | React; evaluate the need to remove the cause; implement; “review the effectiveness of any corrective action taken”; keep evidence | The single clause your issue tracker evidences better than any purpose-built tool. |
Read that table and the shape of the problem changes. There is no clause requiring a document management system, an ISMS platform or a GRC product. There are clauses requiring that certain information exists, is current, is protected from people who should not change it, and can be produced when asked.
The word that catches people
Controlled, in clause 7.5.3. It means one current version, and permissions that mean not everyone can change it. The common text's own note on access: “Access can imply a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information.”
Stack by stack
Microsoft 365 only
SharePoint or Teams for documented information, Entra ID for access, Purview for classification and retention, Intune for endpoints, Defender for monitoring.
What it evidences well. Version history and approvals in SharePoint satisfy clause 7.5.2 and 7.5.3 without any extra product. Entra ID access reviews evidence A.5.18. Intune compliance policies evidence a large part of A.8.1 and A.8.7.
What to plan for. Retention and disposal. A.8.10 requires information to be deleted when no longer required, and a SharePoint library with no retention label is the default state. Also the risk register: there is no natural home for it, so it ends up in a spreadsheet nobody versions.
Jira and Confluence
Confluence for the documented information, Jira for corrective actions, risk treatment tasks and internal audit findings.
What it evidences well. Jira is unusually good evidence for clause 10.2. A nonconformity with an owner, a date, a linked change and a closure comment is exactly what an auditor wants to sample, and the workflow history is tamper-evident enough to be credible.
What to plan for. Confluence page permissions drift as spaces grow and people move teams. If the Statement of Applicability is editable by everyone, clause 7.5.3's control requirement is not met. Set page restrictions and be able to show them.
Azure DevOps
Repos and pipelines for the technical controls, Wiki for documented information, Boards for actions.
What it evidences well. Branch policies, required reviewers and pipeline gates are strong evidence for A.8.28 secure coding, A.8.9 configuration management and A.8.32 change management — and can be stronger than what a team using a compliance platform can produce, because it is the real control rather than an attestation about it.
What to plan for. Azure DevOps Wiki has weaker approval semantics than the alternatives. Policy approval can end up as a pull request, which works but needs explaining. And the split between what lives in Azure DevOps and what lives in Microsoft 365 is where documents go missing.
GitHub and Google Workspace
GitHub for code and infrastructure, Google Docs or Drive for the documented information.
What it evidences well. GitHub branch protection, CODEOWNERS and required reviews evidence the development controls directly. Drive version history covers 7.5.2.
What to plan for. Google Docs approval is informal — there is no built-in approved state, so you need a convention and it has to be applied consistently. Drive sharing defaults are the same problem as Confluence permissions, with the added risk of link sharing.
A compliance platform
Purpose-built ISMS software collecting evidence from your systems automatically.
What it evidences well. Removes the evidence-gathering work, which is tedious rather than difficult, and keeps the management system visible between audits, when nobody is preparing for anything.
What to plan for. It cannot decide your scope, write your risk treatment or hold your management review, and it is a permanent subscription. A platform full of evidence against a scope nobody thought about is still a Stage 1 finding.
Shared drive and spreadsheets
A folder structure, Word documents and a risk register in Excel.
What it evidences well. Entirely capable of passing an audit, and plenty of certified organisations run this way. The standard asks for documented information to be available, protected, controlled and retained. A well-run folder does all four.
What to plan for. “Controlled” is the word that bites. Two copies of the information security policy with different dates fails “control of changes (e.g. version control)”, and it is what a shared drive produces by default.
ISO 27001 for DevOps teams: what a pipeline can evidence
A team that ships through a pipeline already produces much of the evidence for the development and change controls. The mapping below uses ISO/IEC 27002:2022 control titles (from its contents; we have not quoted control text) and is our reading of where the evidence sits.
| Control | Title | Where the evidence can come from |
|---|---|---|
| 8.4 | Access to source code | Repository permissions and branch protection |
| 8.8 | Management of technical vulnerabilities | Dependency and image scanning results, with fix dates |
| 8.9 | Configuration management | Infrastructure as code and its review history |
| 8.15 | Logging | Pipeline and platform logs, retained |
| 8.25 | Secure development life cycle | The documented workflow from ticket to release |
| 8.26 | Application security requirements | Security requirements recorded in tickets or design documents |
| 8.28 | Secure coding | Code review records and linting or static analysis output |
| 8.29 | Security testing in development and acceptance | Automated tests and their results in the pipeline |
| 8.31 | Separation of development, test and production environments | Separate accounts or projects for dev, test and production |
| 8.32 | Change management | Pull requests with required approvals, and release records |
Change control is a management-system requirement too
Beyond the control set, the common text ISO 27001 applies says: “The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary.” A pipeline that records who approved what and when, and what happened after, is evidence for that sentence as well as for 8.32.
What the pipeline does not cover
The risk assessment, the Statement of Applicability, the internal audit and the management review are not produced by tooling. Neither are the people and physical controls. See Statement of Applicability and the checklist.
Where tooling findings actually come from
Across all of these, two problems come up whatever the product, and neither is solved by buying something.
1. Permissions
An ISMS wiki that everybody can edit does not meet the control requirement in 7.5.3, whichever product it lives in. Confluence and Google Drive default to open within an organisation; that default is convenient and it works against “it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity)”. Restrict the ISMS space, and be able to show the restriction rather than assert it.
2. Duplication
Two copies of the same policy with different dates. A shared drive produces this by default, a wiki produces it when somebody exports to a document for a customer, and Microsoft 365 produces it when the same policy exists in Teams and in SharePoint. The fix is a convention about where the single current version lives, applied consistently, and it costs nothing.
What good tooling does and does not buy you
It is worth being clear about which benefits are real, because the distinction is easy to blur.
- It does not shorten the audit. Audit days come from ISO/IEC 27006 audit time table, reproduced in full in an accredited certification body's published audit-duration procedure (QSI-TL.04 rev 21) and are a function of headcount, sites and complexity. No tool moves them.
- It does reduce your own staff time during the audit, which is a genuine and underrated cost. Being able to produce an access review in thirty seconds rather than thirty minutes changes how a three-day audit feels.
- It does reduce the probability of a finding, mostly by making it obvious when something has lapsed — which matters more in year two than in year one, because year two is when the management system quietly stops being maintained.
- It does not decide anything. Scope, risk appetite, risk treatment and the management review are decisions, and no software makes them.
A reasonable default
For a team of under about fifty people that already runs on one of these stacks, the sequence that wastes the least money is: use what you have, fix the permissions and the duplication first, keep the risk register somewhere versioned rather than in a spreadsheet on somebody's desktop, and revisit tooling after the first surveillance audit — when you know from experience which part of the upkeep is actually painful.
Buying an ISMS platform before the first audit means choosing a tool to solve problems you have not met yet. Buying one after the first surveillance audit means choosing it to solve the ones you have.
Where to go next
Common questions
Is ISO 27001 compatible with DevOps?
Yes. The standard does not require any particular delivery method. A pipeline can evidence several ISO/IEC 27002 controls, including 8.25 Secure development life cycle, 8.28 Secure coding, 8.29 Security testing in development and acceptance, and 8.32 Change management. The management-system parts (risk assessment, Statement of Applicability, internal audit, management review) still have to be done outside it.
Can we build an ISMS in Confluence and Jira?
Yes, and an auditor cannot require otherwise. ISO/IEC 27001 is technology-neutral: the common text of clause 7.5.3 asks that documented information be “available and suitable for use, where and when it is needed” and “adequately protected”, with control of changes and “retention and disposition”. It names no product. Confluence handles the documents and Jira is unusually good evidence for clause 10.2, because a nonconformity with an owner, a date and a closure comment is exactly what gets sampled. The one thing to fix first is page permissions: an ISMS wiki that everyone can edit does not meet the control requirement.
We only have Microsoft 365. Is that enough?
Yes, and you have more of the technical controls covered than you probably think. SharePoint version history and approvals satisfy clause 7.5.2 and 7.5.3; Entra ID access reviews evidence access control; Intune compliance policies evidence endpoint controls; Purview covers classification and retention. The two gaps to plan for are retention and disposal under A.8.10, which does not happen by default, and the risk register, which has no natural home and can become an unversioned spreadsheet.
Can we use Azure DevOps for the ISMS?
For the technical controls it is a strong option, and can be stronger than what a compliance platform can produce: branch policies, required reviewers and pipeline gates are the real control rather than an attestation about it, and they evidence secure coding, configuration management and change management directly. The weaker area is policy approval, because the Wiki has looser approval semantics than SharePoint or Confluence. Approving policy by pull request works and needs a sentence of explanation at Stage 1.
Does an auditor prefer a particular tool?
No, and a certification body cannot require one. What auditors respond to is whether the evidence can be produced when asked, whether there is one current version of each document, and whether the people who own controls can describe what they actually do. A team running the whole thing in a well-kept shared drive and answering confidently does better than a team with expensive software and no one who can explain the scope.
Will a compliance platform make the audit shorter?
No. The audit length comes from ISO/IEC 27006 audit time table, reproduced in full in an accredited certification body's published audit-duration procedure (QSI-TL.04 rev 21) and is a function of your headcount, sites and complexity. No tool changes it. What good tooling changes is how much of your own staff time the audit consumes and how likely a finding becomes, which are real benefits but different ones.
Do we need a separate document management system?
No. Clause 7.5 asks for documented information to be controlled, and some toolkits assume a formal DMS that the standard does not ask for. It does not ask for a product category. If you can show one current version, who approved it and when, and that the wrong people cannot change it, the clause is satisfied.
Where do tooling-related findings come from?
Two places we would check first. Permissions — a wiki or drive where the ISMS documents are editable by everyone, which fails the control requirement in 7.5.3. And duplication — two copies of the same policy with different dates, which is what a shared drive produces unless somebody is deliberately preventing it. Both are free to fix and neither needs new software.
Sources cited on this page
- ISO/IEC Harmonized structure for MSS with guidance for use (formerly Annex SL Appendix 2 of the ISO/IEC Directives, Part 1), approved 30 July 2025
- ISO/IEC 27001:2022, official preview (clauses 1 to 6.3 and contents), read first-hand
- ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements
- ISO/IEC 27002:2022, Information security controls
- ISO/IEC 27006-1:2024, Requirements for bodies providing audit and certification of information security management systems — Part 1
Every figure above was read from the source it is attributed to on 20 September 2026. Figures that are our own arithmetic rather than a published rule are labelled as estimates wherever they appear. How we check this.
Find out what your stack already covers
Describe what you run in the last box and a consultancy can tell you which controls you are closer to than you think.
Your enquiry is ready to send
Here is what happens after you submit:
- We pass your answers only to ISO 27001 consultancies taking enquiries for your sector, when one is.
- No more than three may contact you, and only using the details you gave.
- You decide who, if anyone, you speak to. You are committed to nothing.
We are not a certification body and cannot issue, arrange or influence a certificate. Only a UKAS-accredited certification body can do that, and you appoint it yourself.