What ISO 27001 actually requires — and how to produce it in Jira

[#1]

ISO 27001 clause 6.1.2 is where most audit findings on risk documentation originate. It requires a documented, repeatable process for identifying, scoring, and treating information security risks — and evidence that you ran it.

---

What clause 6.1.2 actually asks for

In plain English, your risk register needs to show:

• Every identified risk, with a description of what could go wrong and what it affects
• A consistent scoring method — likelihood × impact, applied the same way every time
• A named owner for each risk
• A treatment decision — mitigate, accept, transfer, or avoid
• Evidence that the treatment happened — not just that it was planned
• Residual risk after treatment, showing the score came down to an acceptable level
• A record of when the review happened and who was involved

The register doesn't need to be sophisticated. It needs to be current, traceable, and consistent. Auditors fail teams not because the tool is wrong but because the register was updated the week before the audit and everyone knows it.

---

Where Jira-based registers typically break

The most common ISO 27001 finding on risk documentation isn't a missing field. It's a register that can't answer: "Show me the link between this risk and the work that mitigated it."

A Confluence page can't show that. A spreadsheet can't show that. A Jira board with risk labels can't show that either — not without manual assembly that takes hours and still looks unconvincing to an auditor.

The second common finding: no pre-mitigation score. Teams record the risk after treatment, with a single score, and have no evidence of what it looked like before. ISO 27001 wants both states. The delta between them is what justifies your treatment decision.

---

What the register needs to show, per risk

1. Risk description and affected asset or process
2. Likelihood score — pre-mitigation
3. Impact score — pre-mitigation
4. Combined risk score — pre-mitigation
5. Treatment decision and named owner
6. Linked mitigation task — the actual Jira work
7. Post-mitigation likelihood, impact, and residual risk score
8. Verification that the treatment was completed

If your current process can produce all eight with a direct link to Jira work — you're audit-ready. If it requires manual assembly, you're one audit cycle away from a finding.

---

What we use

We built Risk Manager for Jira to cover this exactly. It covers the risk register requirements for ISO 14971, ISO 26262, ISO 27001, and SOC 2 — identification, automated scoring, pre and post mitigation tracking, residual risk calculation, and a traceability table your auditor can follow without a guided tour.

A colour-coded risk matrix with drill-down shows which issues sit in each risk band.

Format Rules flag unowned or overdue risks automatically.

Risk logic — probability and severity labels — is configurable to match your SOPs or your specific standard.

It won't complete your certification for you, but the data your auditor needs is in Jira, traceable, and current. Available for Jira Cloud and Atlassian Government Cloud. Zero external storage. Try Risk Manager for Jira →

---

Published by Optimizory