Somewhere in your company there is a procedure that says a review happens every six months. Someone wrote it carefully. It was approved, filed, and is genuinely a good procedure. The last time anybody actually ran it was fourteen months ago, and nobody decided to skip it. It simply never came up.
This is not a discipline problem, and it is not solved by writing better procedures or by asking people to be more organized. The reason long-interval work gets missed is structural: nothing in anyone’s week cues it. The fix is to stop asking people to remember at all, and instead let the schedule produce the work as a task that arrives assigned, dated, and carrying its own instructions.
The longest intervals are the ones that fail
Daily and weekly procedures mostly look after themselves. Not because anyone is disciplined about them, but because they ride on rhythms the business already has. The standup, the Monday meeting, the month-end close. The cue is already in the calendar, and the work attaches itself to it.
A six-monthly or annual procedure touches none of that. It sits outside every rhythm the company operates. The interval is longer than a quarter, longer than most planning cycles, and often longer than the time a given person spends holding that particular responsibility. By the time it comes due, the person who wrote the procedure may not be the person who owes the action, and there is nothing in the environment to raise a hand.
Which produces an uncomfortable result. How important a procedure is has almost no bearing on whether it gets done. How often it runs does. The annual disaster recovery test and the daily backup check may both be critical, but only one of them has a fighting chance of happening without a system behind it.
What you are actually asking someone to do
When a procedure has a frequency and no mechanism, you are relying on what psychologists call prospective memory, the ability to carry out an intention you formed earlier. The research on it draws a distinction that matters here. In event-based prospective memory, you act on the intention when you notice a pre-established cue. Without that cue, retrieval depends instead on effortful monitoring, which means actively holding the intention yourself rather than being prompted by something in front of you.
Researchers have also noted that laboratory conditions only partly reflect how remembering intentions works in everyday environments, which is why naturalistic studies exist at all. The practical translation is straightforward. Nobody monitors an intention for six months. What people actually do is hope the thought surfaces at roughly the right time, which is a coin toss dressed up as a process.
There are two costs, and the obvious one is the smaller of the two. The first is the missed execution. The second is the mental load of carrying it, which is charged continuously rather than only when the work falls due. Holding “I need to review the supplier contracts around March” occupies something in a person’s head for months, and it does so whether or not they eventually remember.
People do compensate. They set a calendar entry, keep a spreadsheet, or leave themselves a note. Those workarounds are worth respecting, because they are evidence someone cared. But they are personal rather than organizational. When that person changes roles or leaves, the reminder system leaves with them, silently, and nobody finds out until the thing that was supposed to happen twice a year has not happened for two years.
This is not a compliance problem, it is a company problem
The word procedure makes people think of auditors, which is why this gets treated as a compliance concern and quietly ignored by everyone else. In practice every team in a company has periodic work on a long cycle, and every one of them fails at it for the same reason.
- The technical team: general systems maintenance every three to six months. Framework and runtime upgrades to stay current and supported, server patching, endpoint and machine health checks. Worth noting that upstream release and end-of-life dates are set by somebody else entirely, so the deadline is externally imposed and completely indifferent to whether anyone on your side remembered.
- The sales team: reviewing the runbook every six months so it still reflects what actually wins deals rather than what was true two pricing changes ago.
- Support and customer facing teams: working through a check-in round every six to twelve months so quiet accounts get a conversation before they become a renewal surprise.
- Operations and finance: supplier and contract reviews, licence and certification renewals, data retention clean-ups.
None of these are compliance activities in the way most people use the word. All of them are procedures with a frequency, and all of them are exposed to exactly the same failure. Each team then invents its own private workaround, which is four fragile systems where there could be one reliable one.
The procedure most of your team has never read
It helps to separate the two layers, because they behave completely differently in practice.
Policies are the layer everyone is meant to read and acknowledge. That part is a solved problem and most organizations handle it: you publish the policy, assign it to the people it applies to, and track who has signed off. In ISO Mate that is an attestation cycle, where a published policy goes to user groups and completion is tracked against a threshold, covered in Managing Policies and Attestations.
Procedures are the layer underneath, and almost nobody reads them voluntarily. A policy might state that access rights are reviewed periodically. The procedure is the eleven steps that make that true. Realistically, the people who will one day perform those eleven steps have not read them, and may not know the procedure exists.
Here is the part worth sitting with: they do not need to have read it, as long as the procedure comes to them when it is due. When ISO Mate generates a task from a procedure, the task does not just say “go and do the thing”. It carries the procedure’s category, the version number that was current at the time, the overview, and the numbered steps, inside the task itself.
That inverts the usual model. Instead of documenting a procedure just in case, training people on it once, and hoping recall survives the next eighteen months, the instructions arrive attached to the work at the moment they are needed. Recall stops being part of the design. It also means the honest answer to “does everyone know our procedures” becomes less important than “does the procedure reach the right person when it matters”, which is a far easier thing to guarantee.
What a system that does the remembering looks like
Mechanically it is a small amount of setup, done once per procedure. Publish the procedure, leave it Active, and give it a recurrence pattern. From then on the schedule runs itself. The full walkthrough is in Managing Procedures, but the pieces that matter for this problem are these.
- The recurrence pattern: Daily, Weekly, Monthly, Quarterly, Yearly, or Custom. There is no six-monthly preset, so the case at the centre of this article is a Custom pattern with an interval of six months. Custom takes any interval in days, weeks, months, or years, so twice-yearly, every eighteen months, and every three years are all expressible.
- The execution window: the number of days allowed to finish once the procedure becomes due, which becomes the generated task’s due date. This keeps the schedule and the deadline as separate ideas, so a procedure can come due on the first of the month with a fortnight to complete it rather than implying it must all happen that day.
- The assignee: the task arrives already assigned to a named person, who receives a notification. Not a broadcast to everyone, and not a task sitting unowned in a queue, which is the state most reminders die in.
- Completion rolls the schedule forward: finishing the task stamps Last Executed and moves Next Due to the following occurrence. Nobody maintains the schedule, and there is no annual ritual of resetting reminders.
- No stacking: while a task for a procedure is still open, another one will not pile up behind it, so a busy fortnight does not leave you with four identical tasks and no idea which to close.
Two further things make this usable rather than merely automatic. A published procedure has a Generate Task action for when you need a cycle on demand, outside the schedule. And the procedure view carries an Execution History panel listing every task it has produced, with due or completed dates and status, alongside Next Due and Last Executed.
The most useful part for anyone managing across teams is what happens when something slips. A procedure whose occurrence has passed without the work being picked up shows a compliance status of Non-Compliant, and the procedures list can be filtered by that status. So the question “what have we quietly stopped doing” becomes a filter you apply in a few seconds, rather than an investigation you launch after something goes wrong.
For the routines that will never be written up as formal procedures, and there will always be some, recurring tasks in Creating and Managing Tasks do the same job with the same patterns, plus an optional end date or a fixed number of occurrences.
A short note on the audit consequence
Most readers will care about this for operational reasons, and that is reason enough. But if your company is certified against a standard, or is heading that way, there is a detail worth knowing.
A nonconformity is the non-fulfilment of a requirement, and that includes requirements set by your own documentation, not just by the standard. The textbook example of a major nonconformity is precisely the gap this article is about: a procedure requiring a daily backup, where the backup was in fact performed a handful of times a month at random.
So writing down the frequency is what creates the obligation. The document produced to demonstrate that you are organized becomes the standard you are measured against, and stating a six-monthly review while performing it once every fourteen months is a worse position than never having written it down. The upside is that Execution History is exactly the record an auditor asks for, and it accumulates as a byproduct of doing the work rather than being reconstructed the week before a visit.
Where to start this afternoon
Do not start with the procedures you run every week, because those are already working. Start at the other end. List the procedures with the longest intervals, the six-monthly and annual ones, and be honest about when each was last actually performed. That list is your real exposure, and for most companies it is shorter and more alarming than expected.
Then, for each one, do three things: set the recurrence pattern, set an execution window you can genuinely live with rather than an aspirational one, and name an assignee. That is the whole intervention. The work stops depending on anyone holding it in mind, and the next occurrence arrives as a task with the steps already in it.
If you want to try this against your own procedures, ISO Mate Compliance Management includes it, and every account starts with a 14-day free trial, which is long enough to schedule your neglected annual procedures and watch the first tasks land.