ISO 27001 compliance software should help your team run an information security management system, or ISMS, and retrieve the decisions and records an independent auditor asks to see. It cannot decide which risks your organisation accepts, operate a missed control or issue a certificate. The useful buying test is to take one real risk through treatment, control operation, evidence review and an audit request. If the software loses the thread at any point, a polished readiness score is not enough.
ISO/IEC 27001:2022 is the requirements standard for an ISMS. Its risk process adapts to the organisation and its needs. Bring your own scope, risk and actual source records to the demonstration. Check whether the tool makes daily control work easier to operate and inspect, then read the ISO 27001 certification guide for the broader certification path.
| Requirement | Record to inspect in the demo | Human decision the tool cannot make |
|---|---|---|
| Clause 6.1.3: risk treatment | Treatment decision, selected controls and Statement of Applicability | Whether a risk and control choice is appropriate |
| Clause 7.5: documented information | Approved version, owner, date and access history | Whether the document describes the real process |
| Clause 8.1: operational planning | A dated control occurrence and exception | Whether an exception is acceptable |
| Clause 9.2: internal audit | Audit plan, finding, owner and follow-up | The independent audit judgement |
| Clause 9.3: management review | Inputs, management decision and action | Leadership accountability |
| Clause 10.1: improvement | Nonconformity, corrective action and verification | Whether the action addressed the cause |
Use the published ISO/IEC 27001:2022 requirements and your licensed copy of the standard for the exact wording and applicable scope.
What must ISO 27001 compliance software actually record?
Begin with the system boundary. Name the service, teams, locations, important suppliers and information assets the ISMS covers. Ask the vendor to show how that scope appears beside a risk and its owner. A control catalogue that cannot tell whether a control applies to your service is a reference library, not an operating record. The standard expects a risk process suited to your organisation; a universal set of green boxes cannot establish that fit.
Ask for the version of a policy in force when a control operated. The reviewer should be able to see who approved the document, when it changed and which evidence belongs to the earlier version. If an integration refresh silently overwrites the original record, you may lose the context the auditor needs. Ask how the tool retains source references, versions and deletion history, and test export before signing a contract.
Next, ask where the exception lives. If a monthly review was late, the system should preserve the late date, the reason, the owner’s decision and the corrective action. A dashboard that turns green after a new upload must not erase a missed occurrence. This is also a test of your own process: a tool can organise a gap only if someone owns and resolves it.
Can it trace a risk to a control and a decision?
Bring a risk from your environment, such as inappropriate privileged access to production. Show the initial assessment, the person responsible, the treatment decision and the control chosen to reduce it. Then ask the vendor to open the control’s operating evidence. The chain should be understandable by someone who did not attend the setup meeting. A risk score with no treatment owner or proof of operation is not the same as a managed risk.
Test a changed assumption as well. If the service adds a new cloud account or outsources a support function, can an owner reassess the risk, explain the new decision and keep the old record? The question is about traceability, not automatic scoring. An algorithm can suggest a control; management must decide whether it fits the risk and must operate it. Ask who can approve changes and whether that approval is visible in the export.
Evidr publishes control mapping and evidence review features on its evidence collection page. Test them with your own risk and a record from the system that runs the control. If the mapping is wrong, a human reviewer should be able to correct it and preserve the decision. Do not accept a demonstration that uses only preloaded sample evidence.
How should the Statement of Applicability work?
The Statement of Applicability, or SoA, is not a decorative table of Annex A check marks. The ISO/IEC JTC 1/SC 27 auditing practice note explains that it records necessary controls, the reasons for their inclusion, whether they are implemented and reasons for excluding Annex A controls. It also addresses controls selected outside Annex A. Ask the vendor to show all of those fields and the link back to the risk treatment decision.
Choose one included control and one excluded control during the demo. For the included control, ask why it is needed, how it is implemented and who owns it. For the excluded one, ask to see the recorded justification and who approved it. Then ask what happens if the risk changes. A static exported SoA that cannot be reconciled with the live treatment plan will create more work at audit time.
Do not assume a product generates a compliant SoA just because a sales page says “ISO 27001 ready”. Ask to inspect the actual workflow with your own selected controls. The SoA is management’s decision record, and the certification body will evaluate the ISMS, not a vendor badge.
Will it preserve evidence across an audit cycle?
Take a recurring control, such as access review, and state its promised frequency. Ask the vendor to display every expected occurrence in a sample period alongside the records it found. For an event-based control, ask it to reconcile the full event population. A screenshot of today’s access setting is useful context, but it does not prove a review occurred on the date your procedure required.
Use a deliberately missing record in the demonstration. Does the dashboard show a gap with an owner and due date? Can the reviewer distinguish a control that did not run from a connector that failed to collect its evidence? These need different fixes. If the source record exists but the connector missed it, repair the collection path. If the review never happened, keep the exception visible and improve the process prospectively.
Check retention and exit terms. You need to know whether the original attachment, its source, review comments, approval and timestamps remain available after a plan change. Ask for a sample export containing a control, its evidence and its history. A neat PDF report may help a manager, but it does not replace source records when an auditor asks a follow-up question.
Which integrations and monitoring features matter?
Choose integrations based on the systems inside your ISMS boundary, not the longest logo strip. For each connection, ask what data it reads, how often it refreshes, which permissions it requires and how it reports an authentication failure. A connection that stops silently can make the dashboard look complete while current evidence disappears. A read-only connection still needs security review, especially if it can see sensitive personnel or production data.
Evidr describes read-only integrations and scheduled evidence collection on its product pages. It also describes expiry tracking and alerts in continuous monitoring. In a test, disconnect an integration or let a sample evidence item expire. Check whether the system marks the record stale, names an owner and preserves the prior version. An alert is valuable only if someone receives it and the remediation can be tracked.
Do not mistake an integration for a control. Importing a list of users does not perform an access review. Pulling a repository setting does not demonstrate that every production change was approved. The people responsible for the process still need to inspect the population, record a decision and follow up on exceptions. Buy automation for repeatable collection and visibility, not for an assurance claim it cannot make.
What should an internal auditor and certification body see?
Clause 9.2 calls for an internal audit. Ask how the tool records the audit plan, scope, findings and follow-up. It should let an auditor inspect a sample without seeing unfinished drafts that management did not approve. It should also let the team preserve a finding and its corrective action rather than quietly replacing the failed evidence. The organisation still needs a competent and appropriately independent internal audit process.
For the external certification body, agree on access and scope before inviting anyone. Evidr’s auditor access product describes scoped read-only access to approved evidence and activity logging. Test that an auditor can find the control, version, source period and approval, and that access can be withdrawn. Ask what the tool exports if the body works in its own portal. A well-organised handoff reduces chasing but does not influence the body’s certification decision.
An external certification body performs the ISO/IEC 27001 certification assessment and makes the certification decision. Evidr helps teams organise preparation and evidence for that process. Ask the vendor and the certification body to describe their respective roles in the contract and demonstration.
Run this purchase demonstration with your own records
- Give the vendor your ISMS scope and one real risk. Ask who owns the treatment decision and how it is versioned.
- Select one necessary control, map it into the SoA and export the rationale and implementation status.
- Import or upload one source record, then inspect its date, reviewer, approval and control mapping.
- Introduce a missing occurrence or failed connection. Check whether the exception remains visible and actionable.
- Grant a test auditor read-only access to approved evidence, then export the same control without the interface.
Score each step by the time your team needed and the quality of the record it produced. Include setup, permissions, internal review, export and ongoing ownership. Ask the vendor to state any features or usage limits in writing and check its current pricing page. Use the result to identify the controls that need work and the evidence collection steps that can be automated.
When is Evidr useful, and when is a simpler system enough?
Evidr brings evidence from multiple owners and systems into one review queue, with mapping, approval and expiry visible alongside each record. Its product pages describe AI-assisted evidence review, control mapping, version history, read-only integrations and scoped auditor access. Test those workflows against a real control from your ISMS.
A controlled spreadsheet, document repository and calendar may be enough for a narrow, stable ISMS with a reliable owner and complete source records. That option still needs access control, versioning, recurring reviews and a workable auditor handoff. A platform adds cost and setup work; it is justified only if it removes more repeated work or reduces evidence gaps. Neither option makes a weak risk decision sound or repairs a control that never operated.
Before committing, ask the prospective certification body whether the proposed scope and record format meet its assessment needs. Then keep ownership with your organisation. Software can make the evidence easier to find. Only your people can decide the risk treatment, operate controls, examine findings and improve the ISMS.