How can a small business verify that its cyber security controls work?

Verifying cyber security controls means proving, with dated and reviewable evidence, that each control is configured correctly, operates as intended and remains suitable for the business risk it is meant to reduce. A control should not be treated as effective simply because a policy exists or a security product is installed.

Start with clear control objectives. For each important control, record what it is intended to achieve, which systems and people it covers, who owns it and what evidence will demonstrate success. For example, an access control objective might be that only authorised users can reach a particular system, that access is appropriate to each role and that leavers cannot continue using their accounts. This makes testing specific rather than subjective.

Define the expected result before carrying out the test. Useful acceptance criteria might include:

• all user accounts have an identified owner and a valid business reason;
• privileged access is limited to approved administrators;
• security settings match the organisation’s documented baseline;
• important events produce records that can be reviewed;
• staff know how to report a suspected security issue;
• identified weaknesses have an owner, priority and target date for correction.

Check both design and operation. Design testing asks whether the control could work if followed correctly. Operational testing asks whether it is actually being applied consistently. Reviewing an access policy tests design; sampling recent access requests, approvals and account changes tests operation. The two results can differ, so both are needed.

A practical testing record should include the control being assessed, its scope, the systems or records examined, the person performing the test, the date, the method used, the expected outcome, the actual result, supporting evidence and any limitations. Screenshots may be useful, but exported reports, configuration records, audit trails, meeting notes and signed approvals can provide stronger evidence when they show dates, scope and ownership.

Use a mixture of test methods. Document review can confirm that policies, procedures and responsibilities are current. Configuration review can identify settings that do not match the approved baseline. Evidence sampling can test whether processes were followed in practice. Interviews can reveal whether staff understand their responsibilities, although interview answers should be checked against records wherever possible. Independent review provides a further challenge to assumptions, particularly for controls managed by the same person who is responsible for testing them.

Test the parts of the environment that matter most to the business rather than checking only an easy-to-review sample. Include critical applications, cloud services, remote access arrangements, administrator accounts, portable devices, backups and important suppliers where they fall within the control’s scope. If a sample is used, document how it was selected and why it is representative. A small sample cannot prove that every item is compliant, so the conclusion should reflect that limitation.

Test access controls in particular detail. Compare current accounts with the staff and contractor records held by the business. Check joiner, mover and leaver processes, inactive accounts, shared credentials, multi-factor authentication, privileged roles and emergency access arrangements. Confirm that approvals are recorded and that access reviews result in action where permissions are no longer justified. Any exception should have a named owner and an expiry or review date.

Check that security records can support an investigation. Confirm that relevant systems generate logs, that the logs cover the required events and that someone is responsible for reviewing them. Check whether timestamps are consistent, whether records can be altered by ordinary users and whether retention is appropriate for the business’s needs. A log that exists but is incomplete, inaccessible or never reviewed is limited evidence of an effective control.

Use controlled exercises for people and procedures. A tabletop exercise can walk relevant staff through a plausible incident without making changes to live systems. It can test who makes decisions, who records actions, how information is shared and when external assistance is sought. The exercise should assess the process, not embarrass individuals. Record assumptions, delays, unclear responsibilities and decisions that require management approval.

Technical testing must be authorised, scoped and proportionate. Define the systems in scope, permitted techniques, test window, safety precautions, contacts and stop conditions before starting. Avoid unapproved tests against third-party services or production systems. Where a test could affect availability, confidentiality or personal data, obtain written approval and consider using a non-production environment or a controlled sample.

Interpret results consistently. Classify findings according to the risk they create, taking account of affected assets, likelihood, existing safeguards and business impact. Separate a failed control from a missing piece of evidence: the first indicates that the control did not meet its objective, while the second may mean the control operates but cannot be demonstrated. Both require action, but they should not be confused in the report.

Every finding should lead to a tracked corrective action. Record the issue, risk, agreed treatment, owner, due date, dependencies and acceptance criteria. Once the change is made, perform a follow-up test rather than closing the item on the basis of an email or implementation claim. If the business accepts the residual risk instead, record who approved that decision, why it is acceptable and when it will be reviewed.

Retest after change and at planned intervals. Controls can weaken when staff, suppliers, applications, network arrangements or business processes change. Review the testing programme after significant changes and include recurring checks for areas such as access, software updates, configuration standards, logging, supplier assurance and staff awareness. The frequency should reflect the importance and rate of change of each control, rather than applying one schedule to everything.

Management should receive a concise summary showing controls tested, scope and limitations, significant exceptions, overdue actions, recurring weaknesses and accepted risks. This gives decision-makers enough information to allocate resources without presenting a misleading pass-or-fail conclusion. The complete evidence pack should be retained securely, with access limited because it may describe sensitive systems and weaknesses.

A small business can carry out many checks internally, but an independent cyber security review can add useful challenge where technical knowledge, impartiality or testing experience is limited. S2 Technology Group can help businesses structure control reviews, examine technical evidence and turn findings into prioritised improvement actions, while the business retains responsibility for approving its risks and decisions.