TinyGRC Compliance
Simplifying Governance, Risk, and Compliance.
TinyGRC is an app for the Atlassian Confluence that helps you track basic compliance and visualize overall performance. Track SOC2, PCI, ISO 27001, NIST CSF, NIST 800-53, and HIPAA compliance efforts among others.
ISO 27001:2022 Evidence Management for Small Teams
ISO/IEC 27001:2022 is now the only version that matters — the transition from the 2013 revision closed at the end of 2025, so every new certification and every recertification runs against 2022. The ISMS clauses (4–10) are largely familiar if you’ve seen the 2013 standard. The part that changes your evidence work is Annex A.
What changed in Annex A — and why it matters for evidence
- 93 controls instead of 114, reorganized into four themes: Organizational (37), People (8), Physical (14), and Technological (34).
- The old A.7/A.8/A.9/A.10 numbering is gone. If your control register still references the 2013 numbers, your Statement of Applicability (SoA) is already out of date.
- New or sharpened controls that directly change what you must evidence, notably:
- A.5.24 – Information security for use of cloud services (you need cloud supplier security evidence: contracts, certifications like SOC 2 from your providers, review records)
- A.5.25 – ICT resilience and A.5.26⁄5.27 – monitoring & logging
- A.5.28 – Use of cryptography
- Reorganized identity and access controls (the old A.9 became A.5.15–A.5.19)
The practical effect: your SoA must map all 93 controls (applied or justified-out), and each applied control needs evidence of design (how you do it) and operation (that you actually do it, with dated records).
Mapping controls to where the evidence lives
For a small team the fastest path is a one-row-per-control register, in a format you can keep in a wiki or app:
| Control | Name (short) | Owner | Evidence link | Frequency | Last verified | Notes |
|---|---|---|---|---|---|---|
| A.5.15 | Access control | IT lead | [policy + review log] | Quarterly | 2026-10-01 | Access reviews |
| A.5.24 | Cloud services | CTO | [AWS SOC2 report + contract] | Annual | 2026-06-15 | Covers SSO + storage |
| A.8.7 | Change mgmt | Eng lead | [change records page] | Per change | — | CI/CD approvals |
| A.5.27 | Logging | IT lead | [log retention config] | Continuous | 2026-09-01 | 12-month retention |
“Last verified” is the field assessors care about most — it turns a static document into a live control.
The gaps small teams hit most
From real ISO 27001 assessment work, the same handful of controls surface again and again:
- A.5.15 (Access control) — you have MFA, but no dated access review records. The review, not the control, is what’s missing.
- A.5.19–A.5.21 (Supplier security) — you use cloud and SaaS tools but have no supplier review records. A.5.24 makes this explicit now.
- A.8.1 (Technical vulnerability management) — scans exist, but there’s no record of what was found, fixed, or accepted.
- A.5.27 (Logging) — logs exist, but retention and review aren’t documented.
- SoA itself — copied from a template, not justified per control, with the 2013 numbering.
Each of these is fixable in days, not months — but only if you know you have the gap before the assessor does.
A lightweight routine that keeps it current
- Quarterly: run access reviews, risk review, control “last verified” sweep.
- Annual: risk assessment refresh, SoA review, supplier review, management review.
- Continuous: change records, incident log, logging.
If the register and evidence live in the wiki your team already uses, the routine costs a few hours a quarter. If it lives in a spreadsheet three people have edited, multiply that by three.
TinyGRC tracks ISO 27001:2022 (Main Controls and Annex A) inside Confluence — controls, evidence, per-control progress, and an auditor collaboration view. Free trial on the Atlassian Marketplace.
FAQ
What changed in ISO 27001:2022 vs 2013? The ISMS core (clauses 4–10) is essentially unchanged; Annex A went from 114 controls in 14 topics to 93 controls in four themes (Organizational, People, Physical, Technological), with new emphasis on cloud services, logging, monitoring, and ICT resilience. Certifications under 2013 were transitioned by end of 2025.
Do I need a formal GRC tool for ISO 27001? No — the standard requires a documented ISMS, not a specific tool. What it requires is that every control has evidence of design and operation. A well-structured wiki (or a lightweight app built on one) satisfies that; the failure mode is unstructured evidence, not the absence of expensive software.
How is ISO 27001 different from SOC 2? ISO 27001 is an international standard for an information security management system, often requested by enterprise/OEM customers and for cross-border trust. SOC 2 is a US attestation about controls over a specific service, driven by customer trust requirements. Much of the underlying evidence (access control, logging, change management, vendor security) overlaps. See SOC 2 vs HIPAA vs ISO 27001.