We had a supplier do a security check at the end of last year, so we probably do not need to look again this year — that is a question many owners carry privately. They think of a security check as an annual staff medical: do it, collect the report, put it in a drawer, and feel safe for the next twelve months. Until one day the website will not open, or an unpaid hosting invoice and a vulnerability notice arrive together, and it turns out the system has been changing on the inside for six months.
The reverse is just as bad: ask your engineer to watch every single thing every single day and before long fatigue turns it into a formality. This is the eighth piece in our security basics series, and the closing piece of part one, on understanding what you have. Having confirmed your versions in Security Basics 01｜An advisory just landed: how do you know whether it affects you, this one sets a sensible rhythm for security and system checks: what needs looking at monthly, what is fine once a quarter or once a year, and what has to happen the moment something changes.
Why one check a year cannot stop the accidents in between
A company's website and systems are alive: new transaction data is written to the database every day, cloud invoices and platform notices arrive every month, new software security advisories come out every week, and staff join or leave from time to time. If you open it up once a year, you are handing all the risk in between to luck.
The UK's National Cyber Security Centre (NCSC) makes the point in its 10 Steps to Cyber Security: Asset management guidance: as time passes a system environment naturally grows and changes, so an organisation must keep maintaining and validating the accuracy of its asset inventory, and must disable the relevant accounts and credentials as soon as a system or dataset is no longer needed. Its Vulnerability management guidance makes the companion point: vulnerability management is a continuous process spanning the whole life of a system, requiring ongoing awareness of newly emerging threats and failed updates, and it cannot rest on a check at a single point in time.
In other words, a good security rhythm is not everything crammed into one day. It is work split into four different frequencies according to how fast each thing changes and what it costs when it goes wrong.
Rhythm one: weekly to monthly (confirm the machine is alive and the backups are running)
This layer is the system's breathing and heartbeat. If these stop, you may hit an outage or data loss within days. In Hosting, Monitoring, Security Updates: How Much Time DIY Really Costs we laid out what this routine work actually costs in hours:
- Read the error log once a week: pick out the newly appearing errors and decide which need acting on. It takes under half an hour, and it catches small problems before they become a real outage.
- Check server resources and billing notices monthly: look at disk space and memory to see whether either is filling up, and while you are there check whether the cloud platform has sent anything about unusual charges or a forced upgrade.
- Confirm monthly that backups are genuinely being produced: not whether a schedule was set up at the beginning, but going in to see whether the most recent backup file sits somewhere other than the server, and whether its size looks right.
Rhythm two: once a quarter (security updates and a restore test)
Some things are too frequent monthly and too slow annually. The right rhythm is once a quarter, with extra sessions opened for a major urgent vulnerability:
- Routine security updates: take the language, framework and package security patches accumulated over the period, run them through a test environment first to confirm nothing existing breaks, then apply them to production.
- Actually test a restore from backup: as Does Your AI Product Have Backups: The Minimum Standard for Database and Files put it, a backup you have never restored from counts only as a hope. Pick one day each quarter, genuinely pull the backup into a test environment and run it, and confirm the data really does come back when you need it.
- Review the admin and supplier accounts still in place: go through the administrator accounts that remain open and check that every one of them is still in use.
Rhythm three: once a year, or immediately when something changes
With the monthly and quarterly basics steady, two remaining categories are managed annually or by event:
- The annual stocktake: review the whole architecture for versions approaching End of Life that need an upgrade planned in advance, check whether the card auto-renewing your domains and certificates has expired, and run an overall system health check or deeper assessment.
- Things done the same day a change happens (they cannot wait for month end or quarter end): disable the account the day a member of staff leaves or moves role, withdraw access the day an outside supplier's engagement ends, and check your versions the same week a high-risk advisory arrives. If these wait for the year-end clean, the time in between is a window with the front door wide open.
One table: the four rhythms of a company security check
You can print the table below or send it to whoever looks after your systems, and confirm your own check rhythm has not left a cell empty:
| Check frequency | Core items to look at | Why this frequency |
|---|
| 1. Weekly / monthly | Error logs, server disk and resources, platform billing notices, whether backup files are being produced normally | A full disk or a stopped backup affects trading directly, within a short time |
| 2. Quarterly | Routine security updates to packages and environment, an actual restore test, a review of the account list | Balances stability against security, and stops updates being deferred until they become a major migration |
| 3. Annually | Health check of the overall architecture, a look for technology approaching end of support, confirmation of domains and contracts | Prepares the upgrades and the budget for the next stage in advance |
| 4. Immediately on change | Close the account the day someone leaves, withdraw supplier access the day a project closes, check versions the week a major advisory lands | Deferring any of these produces direct exposure |
Give the rhythm to a system, not to someone's memory
Having seen the four frequencies, you can see why an owner occasionally remembering to ask does not work. People forget when they are busy, especially about quarterly restore tests and weekly log reading — work that feels unrewarding and does not blow up immediately if skipped.
As Hosting, Monitoring, Security Updates: How Much Time DIY Really Costs calculated, "three things break down into six routine jobs", including "reading the error log weekly: pick out the new errors, decide which need acting on, about 30 minutes", "confirming backups: the backup ran, the file genuinely exists, and it sits somewhere other than the server, about 20 minutes", and "a quarterly restore test: actually restore once and confirm the data comes back, about 2 hours" — adding up to roughly 6 to 8 hours a month. If nobody in your company can set that time aside reliably, the honest answer is to give it to a partner whose job is long-term operations.
Nerd Technic is a systems software company that came out of custom development, and what we do now is the long-term maintenance of AI systems. Long-term maintenance means the server and the monitoring have someone watching them daily, and security updates, off-site backups and scheduled restore tests all run to a fixed rhythm, without you having to keep them in your own calendar. If you want to know which of these frequencies the system you have is missing most, a system health check is a place to start: Book a system health check
Security
