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.

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.

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.

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.

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.

Sources

Source: CIS Critical Security Controls list — cisecurity.org/controls/cis-controls-list, retrieved 2026-10-21 (the 18 CIS Critical Security Controls of version v8.1, described as a prescriptive, prioritized, and simplified set of best practices, with revised asset classes and Safeguard descriptions and the addition of the Governance security function; the control names from Inventory and Control of Enterprise Assets through Penetration Testing).

Source: CIS Critical Security Controls Implementation Groups — cisecurity.org/controls/implementation-groups, retrieved 2026-10-21 (a total of 153 Safeguards in CIS Controls v8 and v8.1; every enterprise should start with IG1, defined as essential cyber hygiene, the foundational set of cyber defense Safeguards that every enterprise should apply to guard against the most common attacks; IG2 builds upon IG1 and IG3 comprises all the Controls and Safeguards).

Source: 10 Steps to Cyber Security — National Cyber Security Centre, ncsc.gov.uk/collection/10-steps, published 11 May 2021, retrieved 2026-10-21 (guidance aimed at medium to large organisations that have someone dedicated to managing cyber security; for smaller organisations the Cyber Action Toolkit might be a better place to start, though the principles are applicable to all organisations; the ten components are Risk management, Engagement and training, Asset management, Architecture and configuration, Vulnerability management, Identity and access management, Data security, Logging and monitoring, Incident management and Supply chain security).

Source: Cybersecurity Framework — NIST, nist.gov/cyberframework, retrieved 2026-10-21 (CSF 2.0 for industry, government, and organizations to reduce cybersecurity risks; a voluntary framework created through collaboration between industry and government; Framework Profiles as an organization's unique alignment of its organizational requirements and objectives, risk appetite, and resources against the desired outcomes of the Framework Core, used to identify and prioritize opportunities for improving cybersecurity).

Source: Critical Vulnerabilities in PHP Require Immediate Patching — CISA alert, cisa.gov, 21 October 2026, retrieved 2026-10-21 (CVE-2026-109618 and CVE-2026-109619 affecting all PHP installations serving web requests; the instruction to identify and inventory systems running any version of PHP, with the note that PHP is often a component of other software and prevalence may not be directly observable; priority for internet-facing systems; a web application firewall may provide some protection until systems are updated; monitoring for PHP worker processes launching shells or downloading tools; the instruction to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and to take PHP-based systems offline for organisations that cannot update immediately or that use PHP 8.1 or earlier unsupported versions).

Source: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 security release — php.net archive, retrieved 2026-10-21 (two critical vulnerabilities allowing unauthenticated remote code execution; PHP 8.1 and older no longer receive updates from the PHP project, with minimal source backports for PHP 7.4, 8.0 and 8.1 provided by the PHP security team for people building from source or without access to an LTS vendor; distributions and LTS vendors received the patches in advance).

Source: the CIS Controls list and Implementation Groups pages, the NCSC 10 Steps collection, the NIST Cybersecurity Framework page and the CISA and php.net advisories of 20-21 October 2026, all retrieved 2026-10-21 — every reference figure and quotation above traces to one of those pages, and the hour estimates are Netics analysis. Images are captures of the CIS Controls list and the NCSC 10 Steps collection, plus two Netics editorial diagrams. Netics runs security audit and hardening engagements for companies of this size, and the free audit reviews a company's systems and processes, on site or remotely, and names what to fix first.