A Security Audit Checklist for a 20-Person Company

TL;DR

• A security audit is a review that checks whether a company's systems, accounts and backups behave the way the company believes, and it ends in written evidence a client, an insurer or a future enterprise customer can read.
• At twenty people the work fits a single week: an inventory, accounts and admin rights, a patching clock, one verified restore, logs, suppliers and an evidence pack.
• Two public reference frameworks carry the inventory: CIS Controls v8.1 with its 18 controls and 153 safeguards, where Implementation Group 1 is defined as essential cyber hygiene, and NCSC's 10 Steps with ten named components for organisations that have somebody on security.
• Accounts come first, because a list of who holds admin, a second factor on every account that reaches production and a trail for joiners, movers and leavers answers most of a client questionnaire on its own.
• Patching runs on a published clock with a named owner, and the reason is timing: when PHP fixed CVE-2026-109618 on 21 October 2026, CISA urged applying the patch immediately, with priority for internet-facing systems.
• Backups count on the day somebody restores one from the copy that leaves the building, with the date written into the evidence pack.
• Logs earn their place when a dashboard exists that a named person opens, and the archive keeps the one path an investigation would need to reconstruct.
• Suppliers hold the data, so every contract gets the same three questions, and the evidence pack gathers the answers in one folder.
• Four people can carry the week: one owner, two technicians, and one person from finance or operations who reads the result.

What a security audit produces at twenty people

A company of twenty runs on a laptop fleet, a handful of cloud accounts, a website somebody built, a shared drive and two or three business applications. Nobody in that company spends their day on security, and the honest starting point of the audit is a sentence the founder can say out loud: this is what we own, this is who can reach it, and this is how we would know if something changed.

Netics editorial card counting what the public reference lists contain: 18 CIS controls in v8.1, 153 CIS safeguards, the 10 NCSC Steps and the 3 CIS Implementation Groups.

The output of the audit is a document with rows in it. Each row names an asset or a process, the person who owns it, the state it is in today, and the date somebody checked. A penetration test answers a different question and produces a different artefact, which is why a small company that buys one test a year can still fail a client questionnaire that asks whether the staff laptops are encrypted, whether admin accounts use a second factor, and when a backup was last restored.

Three audiences read that document. A client's procurement team reads it before signing, an insurer reads it when pricing a cyber policy, and an enterprise customer reads it when a twenty-person supplier asks to connect to their systems. Each of those conversations has a shorter, cheaper version once the rows exist, and a longer, more expensive version when they have to be produced under deadline.

The inventory comes before the framework choice

Three public lists cover the same ground, and a company of twenty can use any of them as scaffolding for the rows. CIS Controls v8.1 is the most prescriptive: 18 controls, 153 safeguards, and Implementation Groups that let a smaller organisation start with Group 1, which CIS defines as essential cyber hygiene, the foundational set of safeguards every enterprise should apply against the most common attacks. NCSC publishes the 10 Steps to Cyber Security as guidance aimed at medium to large organisations with a dedicated security role, and says plainly that smaller organisations may be better served by its Cyber Action Toolkit while the ten principles still apply. The NIST Cybersecurity Framework, current version 2.0, works one level up: profiles describe an organisation's own alignment of requirements, risk appetite and resources against the framework's outcomes, and are used to prioritise what to improve.

The practical move is to pick one list as the spine and write the rows against it. A twenty-person company that adopts CIS Control 1 and Control 2 ends up with two spreadsheets: every device and where it lives, and every piece of software with its version and its owner. That second sheet is where the audit starts paying for itself, because the software nobody remembers installing is the software nobody patches. CISA made the same point about PHP during the October 2026 emergency, warning that the language is often a component of other software and that its prevalence may not be directly observable.

The CIS Critical Security Controls list page (cisecurity.org/controls/cis-controls-list, retrieved 2026-10-21), which numbers the 18 controls of v8.1 from Inventory and Control of Enterprise Assets through Penetration Testing.

Accounts, admin rights and a second factor

The account section is the one that produces findings fastest. CIS Control 5 covers account management and Control 6 covers access control management, and both reduce to a question a technician can answer in an afternoon: which identities can reach production systems, and which of those hold administrative rights.

Start with a per-system list. For each business application and each cloud console, write down the administrators, the service accounts, and the accounts that exist because a contractor needed them once. The per-person view follows, and it catches the pattern that small companies share: one shared administrator login, used by three people, with a password that lives in a chat message.

Three checks close the section. The first is the second factor, present on email, on the virtual private network and on every console that can delete data. The second is the departure trail, meaning the written procedure that removes access on the person's last working day. The third is the count: how many administrators exist, and whether that number matches what the founder expected before the list was drawn.

Patching on a published clock

Every reference list treats patching as continuous work, and CIS Control 7 names it continuous vulnerability management. At twenty people the work happens when somebody remembers, which is the failure mode the clock removes. A written rule assigns each severity a deadline, names the person who checks the vendor feeds, and describes what happens when a critical fix lands at the end of a week.

The PHP emergency of 21 October 2026 shows why the rule has to exist before the incident. Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, allowed unauthenticated remote code execution, and CISA urged applying the patch immediately, with priority for internet-facing systems. The fix arrived in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, distributions and long-term-support vendors had the patches in advance, and PHP 8.1 and older no longer receive updates from the PHP project, which turns an end-of-life runtime into a migration project. For those branches the PHP security team published minimal source backports for 7.4, 8.0 and 8.1, meant for people building from source or without access to an LTS vendor.

Two rows belong in the evidence pack here. The first lists the runtimes in use and their versions, and the second records the date the last critical fix was applied. CISA notes that a web application firewall may provide some protection until systems are updated, and asks organisations that cannot update immediately, or that still run PHP 8.1 or earlier, to take PHP-based systems offline until they can be patched or updated.

Netics editorial table pairing each reference framework with what it provides and what the company writes down: CIS v8.1 with its 18 controls and 153 safeguards against asset, account and patch rows, the NCSC 10 Steps against one named owner per step, and NIST CSF 2.0 profiles against a current and a target profile.

Backups and one verified restore

CIS Control 11 covers data recovery, and the audit question behind it is narrower than a backup policy: which copy exists, where it lives, who can read it, and when somebody last restored from it. A company that answers those four questions on one page is ahead of most of its size.

The copy that matters is the one that leaves the building. Ransomware reaches network shares and attached drives with the same credentials the staff use, so the row has to name a destination outside that reach, whether that is object storage in a second account or a removable disk in a drawer. Encryption belongs in the same row, because an unencrypted copy of client data in a second location is a second incident.

The verification is a date, and it goes on the calendar. One restore per quarter, on a test machine, of a directory somebody would genuinely miss, with the outcome written down. A restore that fails is the most valuable finding in the whole audit, because it arrives months before a real outage would have delivered it.

Logs, alerts and a dashboard somebody opens

CIS Control 8 covers audit log management, and the small-company version splits into two decisions: which systems keep logs, and which log lines would change somebody's day. Both answer to a named reader, because a log store nobody queries fills a disk and teaches the team to ignore it.

The alert list for a company of twenty is short. Failed sign-ins in volume on the email and remote-access systems, a new administrator account appearing, a large deletion or a bulk file change, and anything that launches a command interpreter from a web server process. CISA's monitoring advice during the PHP emergency names exactly that last pattern, asking defenders to watch for PHP worker processes launching shells or downloading tools, and it works as a template for any web runtime the company runs.

Retention is the second half. An incident discovered in November often started in September, so the archive has to cover the gap between discovery and cause. The design question for the alerts themselves, which is the subject of the monitoring pillar on alert design, sits on top of this: a page that carries the four fields somebody needs is worth ten that carry a metric name.

Suppliers, access and the evidence pack

CIS Control 15 covers service provider management, and NCSC's tenth step covers supply chain security, which puts supplier review inside the same list as the technical work. The three questions are the same for every contract: which company data reaches the supplier, which of the supplier's staff can read it, and what happens to it on the day the contract ends.

Twenty-person companies usually find a handful of suppliers holding more data than expected: the payroll provider, the accountant's portal, the email host, the website agency, the backup service. Each of those belongs on one sheet with the answers and a review date. The sheet doubles as the exit plan, because a supplier that cannot answer the third question is a supplier whose data cannot be removed.

The evidence pack is where everything above lands. One folder, one index, and per section the rows plus the screenshots and the dates: the device inventory, the software inventory, the admin list, the patching record, the restore test, the alert list, the supplier sheet. Filing work that already exists costs an hour; reconstructing it during a client's security review costs a week.

The NCSC 10 Steps to Cyber Security collection page (ncsc.gov.uk/collection/10-steps, published 11 May 2021, retrieved 2026-10-21), whose sidebar lists the ten components from Risk management and Asset management through Logging and monitoring, Incident management and Supply chain security.

Assigning the week across four people

The checklist fits a week when four people share it. One owner holds the document and the deadline, and that person is usually the founder or the operations lead, because every section needs a decision that a technician cannot take alone. Two technicians take the inventory, the account list, the patch record and the restore test. One person from finance or operations takes the supplier sheet and the contract questions, which are administrative work that technical staff tend to defer.

The estimate per section lands near half a day for the inventories, half a day for accounts, two hours for the patch record, two hours for the restore test, two hours for logs and alerts, and half a day for suppliers. That leaves the evidence pack, which takes an hour when the sections are finished and cannot be compressed when they are not.

The cadence afterwards is the part that decides whether the audit was worth doing. Accounts and patching change monthly, so their rows get a short monthly review. Suppliers and backups change slowly, so they get a quarterly one. The audit itself repeats yearly, with the same document, dated, because the second version takes a fraction of the time and turns a one-off exercise into a record that shows improvement.

Originally published on the Netics blog.