The operating rhythm

The recurring rhythm

Weekly · fifteen minutes

Whoever owns the AIMS opens the Overview and reads the "worth your attention" panel.

• Anything unclassified? Classify it, or chase the owner who can.
• Anything flagged for review? That is a system the engine could not place confidently. It needs a person.
• Any evidence due for review, or with no review date? Send each one to its owner to confirm it is still true.
• Scan Activity for anything you did not expect — particularly access grants.

Monthly · an hour

• Work the gap tracker filtered to in progress. Which have actually moved? Which have been "in progress" for three months and are really not started?
• Filter the gap tracker to Implemented, evidence not current: controls claiming implemented with no evidence, evidence nobody has dated, or evidence overdue for review. That list should be empty and never is.
• Read the Remediation column. A control marked implemented with linked Jira work still open, or with all its linked work done and still not implemented, says so when you open it — one of the two is wrong.
• Ask each system owner whether anything about their system has changed enough to reclassify.

Quarterly · half a day

• Re-run the readiness self-assessment. Compare it with last quarter — the movement is the number you take to a board, not the absolute.
• Filter the evidence list to Review due. Each record there needs somebody to confirm it is still true and move its last-reviewed date on.
• Regenerate the Statement of Applicability and the AI System Register, so a current pack always exists.
• Review who has access. Withdraw anything that is no longer needed, and check for grants held by deactivated accounts.

Annually · a day

• Reclassify every system from scratch rather than reviewing last year's answers. It takes two minutes each and it catches drift that a review does not.
• Revisit the AIMS scope statement. Has what you cover changed?
• Regenerate the whole document set and get the AIMS Policy re-approved.
• Read the audit trail for the year. It is the only honest summary of what actually happened.

Moment one · somebody ships a new AI feature

The most common way an AI register goes stale. Make this the routine:

1. Register it before it launches

   Add it at planned or in development. Name, one-line purpose, your role, an owner.

2. Classify it immediately

   Two minutes, and it is the cheapest it will ever be. If it comes back high-risk you have found that out while the design can still change, which is worth a great deal more than finding out after launch.

3. Attach the obligations to the plan

   If it is high risk, the classification result is a list of twelve or seven things with article numbers. That list belongs in the delivery plan, not in a compliance backlog nobody reads.

4. Move it to in use on launch day

   And re-run the classification if anything changed between design and launch. If what changed is your role — you set out to deploy it and ended up providing it — changing the role on the register re-runs the classification with the new role for you, and the audit trail says why the tier moved.

Moment two · a customer's security review asks about AI

Increasingly the reason SME vendors buy something like this: a deal is waiting on a questionnaire. What you can produce in an hour:

• AI System Register — answers "what AI do you use and what does it do?" in one document.
• Statement of Applicability — answers "do you follow a recognised standard?" better than a yes.
• Roles & Responsibilities — answers "who is accountable?"
• Your readiness score, with its date — answers "how mature is this?" without overclaiming.

Send the documents, and say plainly where you are. A vendor who says "we are at 54% against ISO 42001, here is our Statement of Applicability, here is what we are working on" is more credible than one who says they are compliant.

Moment three · the audit

Whether it is a certification body, an internal audit, or a customer's assessor, the shape is the same.

1. Two weeks before: a clean pass

   Regenerate every document. Read the Statement of Applicability yourself, line by line. Every "not applicable" needs a justification you would say out loud. Every "implemented" needs evidence reviewed in the last twelve months; the Statement of Applicability's Evidence column says which do not.

2. Give the auditor Read only access

   They see everything and change nothing. This is better than sending a pack: they can follow a control to its evidence to its history themselves, which is exactly the trail they are trying to establish.

3. Let the audit trail answer the hard question

   Not "is this control in place?" but "how do I know it has been?" The history on each control shows who changed it and when, and it cannot be edited by anyone — including your own administrators.

4. Record findings as controls, not as a separate list

   A finding is a control that is not where you said it was. Change the status, write the note, name the owner, and link the corrective-action issue in Jira to the control. Then the follow-up audit reads the same trail rather than a new spreadsheet, and can see from the control whether that work is done.

Who does the work

In an SME this is usually three people, and it is worth naming them explicitly:

• An owner — often the CTO or a Head of Engineering. Accountable, does the weekly fifteen minutes, presents the quarterly number.
• One or two contributors — the people who actually classify systems and close controls. Usually an engineering lead and whoever holds security or data protection.
• Readers — everyone else who wants to see it: the CEO, the sales lead who answers security questionnaires, your auditor.

It does not need a full-time compliance function, and it does not work as a once-a-year scramble. Fifteen minutes a week from somebody accountable beats a fortnight in March.