ISO 27001 for IT managers 4: make everyday IT work produce useful evidence

Start with the controls your organisation selected

Bring the risk treatment plan and SoA from part 3. This lesson gives implementation patterns for common IT responsibilities; it is not a claim that ISO mandates a particular product, patch deadline or universal list of settings. Match each pattern to your selected controls, obligations and risk decisions.

Use existing service-management tools where they work. A ticket can hold an approval, implementation record and verification result. The ISMS evidence index can point to that ticket instead of copying its contents into another system. Decide who may edit records, how changes are traceable and how long evidence is retained for your needs.

A policy explains the approved rule. A procedure explains how to carry it out. An operational record shows what happened. You need those roles to agree, but not necessarily three separate documents for every activity. Avoid a procedure promising a daily review when the team actually performs it weekly.

Control the documents as well as the technology

Give important documents an owner, approval, version and review arrangements. Make the approved version easy to find, restrict changes appropriately and identify obsolete copies. External documents such as supplier guidance also need a reliable reference when they affect operation. Choose retention and access rules for records deliberately; ISO certification is not a reason to collect personal data indefinitely.

For an exercise, ask an engineer to find the current recovery procedure without help. Then check who approved it, whether its dependencies still exist and where a change would be recorded. If two conflicting versions are both labelled current, resolve that through document control before relying on either during an incident.

Follow an account from request to removal

For a joiner, retain the approved role/access request, the person who authorised it and the implemented permissions. Verify sensitive access rather than assuming a group name describes its effective reach. For a mover, remove old access as well as adding new access. For a leaver, trace the notification time and the actual removal across relevant services.

Include privileged, supplier and integration identities. Record owners and review arrangements; protect recovery methods. When using SSO, examine direct SaaS accounts and tokens rather than assuming central disablement ends every route. Use the service's supported revocation behaviour and test it in a controlled way.

An auditor may choose a person from an HR list rather than the neat ticket you prepared. Reconcile the full process with HR and service owners. Missing notifications are a process weakness to fix, even if IT completed every request it received promptly.

Show how changes are controlled

A useful change record explains purpose, affected services, risk, approval, validation and recovery. Scale detail to the change: a routine application update and a new identity integration do not need identical paperwork. Define how urgent changes receive appropriate authorisation and later review without backdating approvals.

In fictional Merefield, a firewall change supports a new supplier integration. The record identifies the limited connection, service owner, implementation window and verification. After the pilot, the team removes an unused temporary allowance. The evidence connects the business request to the effective rule and its eventual cleanup.

Retain the relevant configuration history securely. Avoid exporting passwords or private keys into tickets. Record enough to reproduce and review the decision without turning the evidence repository into a new collection of secrets.

Separate patching policy from arbitrary dates

Define update priorities and deadlines from risk, vendor information and obligations. If Cyber Essentials is also in scope, its applicable 14-day requirement still needs to be met. ISO 27001 itself is not a blanket rule that every organisation must install every patch within 14 days.

Reconcile deployment reports with the asset population. Track failed installations, unsupported systems and offline devices. Have an escalation route for exceptions, with an owner and a review date. A risk acceptance record should describe the remaining exposure and authority; it must not claim that an unimplemented control is operating.

Prove recovery by using it

Agree recovery objectives with the business owner. A recovery time objective describes the acceptable restoration time; a recovery point objective describes the acceptable loss of recent data measured in time. They are targets to validate, not guarantees created by buying backup software.

Run an authorised restore exercise to an isolated location. Record the selected data, backup point, start and finish times, integrity/application checks and owner acceptance. Do not overwrite production data as a casual test. Include dependencies such as credentials, encryption keys, licences and instructions that must be available during an outage.

Choose measurements that expose problems

Report denominators and age. “47 of 48 managed computers checked within the agreed period; one overdue” is more useful than “98% healthy” without a population. For recovery, show which critical services have a current successful exercise and which do not. For access, show overdue decisions and completed removals separately.

Select a small set of measures that management can act on. Define who collects them, how they are calculated and what triggers escalation. Do not invent historical performance to fill a dashboard. If measurement starts this month, state that and use the first result as a baseline.

Exercise: prepare an evidence trail

Choose a completed access request, a change and a restore exercise. Ask another authorised person to follow each from requirement to outcome. Check dates, approvals, actual scope and verification. Where something is missing, log the gap and improve the normal workflow so the next record is better.

Your deliverable is an evidence map tied to real operations, with honest gaps and owners. Part 5 extends it to the supplier, people and information-handling processes that IT cannot demonstrate alone.

Check your understanding