iso27001partnersRunning an ISMS in the tools you already have
Clause 7.5.3 asks that documented information be available where needed, adequately protected, controlled, retained and disposed of. That is the whole requirement. No auditor can require a particular tool, and no certification body can require you to buy one.
“Can we do this in Confluence?” is one of the most common questions a technical team asks before starting, and it is usually answered with a sales pitch. 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, format, review and approval | 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 where needed, adequately protected, controlled, retained, disposed of | The word that catches people is controlled: one current version, and permissions that mean not everyone can change it. |
| 9.2 Internal audit | Programme, criteria, scope, results reported to management | 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, implement, review effectiveness, retain 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 most common documented-information finding there is: two copies of the information security policy, different dates, both in circulation.
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, and open-by-default is the norm in most installations. 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 — usually 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 tends to 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 — which is when most of them quietly stop being maintained.
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 is the most common documented-information finding there is, and it is what a shared drive produces by default.
Where tooling findings actually come from
Across all of these, two problems produce most of the findings, 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 is the single most common reason a documented-information control fails at Stage 1. 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 vendors in this area are not.
- 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
Can we build an ISMS in Confluence and Jira?
Yes, and an auditor cannot require otherwise. ISO/IEC 27001 is technology-neutral: clause 7.5.3 asks that documented information be available where it is needed, adequately protected, controlled, retained and disposed of. 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 tends to become an unversioned spreadsheet.
Can we use Azure DevOps for the ISMS?
For the technical controls it is one of the strongest options available, and often 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. This is one of the more expensive misconceptions in the area, and it usually arrives with a toolkit that assumes a formal DMS. Clause 7.5 asks for documented information to be controlled. 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 most tooling-related findings come from?
Two places. 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 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:
- Your answers go to ISO 27001 consultancies that advertise for your sector.
- No more than three of them may contact you, 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.