How often should a business review its cyber security controls?
A business should review its cyber security controls at least annually, with additional reviews after significant changes to systems, staff, suppliers or working practices. Controls should also be reassessed following a security incident, a material change in risk, or the introduction of new legal or contractual requirements.
A useful cyber security review programme has several layers: routine checking of control operation, scheduled management reviews and deeper testing of whether controls remain suitable for the organisation’s risk. This is more effective than treating the review as a single annual paperwork exercise.
The frequency should reflect the sensitivity of the information handled, the importance of the systems involved, the organisation’s exposure to external threats and the consequences of a security failure. A business with straightforward systems and limited sensitive data may use a simpler review cycle, while a multi-site organisation, regulated business or company dependent on cloud platforms and remote access may need more frequent and detailed scrutiny.
Routine operational checks confirm that controls are working as intended. These checks may include:
- Reviewing alerts from endpoint, identity, email and network security tools.
- Checking that backups have completed and that restoration tests remain successful.
- Examining administrator activity, unusual sign-ins and failed authentication events.
- Confirming that security updates, malware protection and device configurations are current.
- Reviewing newly created, changed or disabled user accounts.
These activities are often performed continuously or as part of regular IT operations. They are not a replacement for a formal control review, because an alert can show that a tool is active without proving that the underlying process is effective.
Management reviews should examine whether the control environment still matches the business. They should consider changes in the organisation’s technology, suppliers, locations, workforce, information assets and operating processes. Management should also review unresolved weaknesses, accepted risks, overdue actions and exceptions to policy. The outcome should be a prioritised action plan with an owner and a target date for each material improvement.
Technical testing provides evidence that controls work in practice. Depending on the risk, this can include vulnerability assessments, configuration reviews, access-rights checks, phishing-resilience exercises, backup restoration tests and penetration testing. Testing should be independent enough to challenge the people or team responsible for implementing the control. A documented result should explain what was tested, what was found, the risk created by any weakness and how remediation will be verified.
Each review should assess three separate questions:
- Is the control appropriate? Its purpose, scope and strength should correspond to the risk it is intended to address.
- Has it been implemented correctly? Policies, configurations, permissions and technical settings should match the documented design.
- Is it operating consistently? Records, alerts, tickets, training evidence and test results should demonstrate that the control is being applied rather than merely documented.
Evidence is central to a meaningful review. Useful records can include asset inventories, access reviews, patch reports, backup logs, security-alert investigations, supplier assessments, staff training records and incident exercises. Evidence should be dated, retained securely and linked to the control being assessed. Where a control cannot be evidenced, it should be treated as unverified rather than assumed to be effective.
The scope should cover more than firewalls and antivirus software. A comprehensive review normally considers:
- Asset identification and ownership, including cloud services and business-critical applications.
- Identity management, privileged access, authentication and joiner, mover and leaver processes.
- Device security, patching, encryption, configuration standards and mobile equipment.
- Network separation, remote access and protections for externally exposed services.
- Data handling, retention, sharing and recovery arrangements.
- Supplier and third-party connections, including the access they receive and how it is monitored.
- Staff awareness, reporting routes and protection against social engineering.
- Incident response, business continuity and the ability to restore essential operations.
Review frequency should also be based on control volatility. Access permissions, security alerts and backup results need closer operational attention than a policy document that changes infrequently. Conversely, a policy review alone is insufficient if technical configurations, user behaviour or supplier access have not been tested.
Responsibility should be assigned before the review begins. IT teams can provide technical evidence, system owners can confirm business requirements, and senior management should decide how significant risks are treated. Where internal expertise is limited, an independent cyber security specialist can help define the scope, test controls and provide an objective assessment. S2 Technology Group supports organisations with cyber security reviews, risk-led advice and ongoing management of IT controls, helping businesses turn findings into practical improvements.
A review is complete only when its findings have been recorded, prioritised and followed through. The next review should begin with the previous action plan: confirm which weaknesses were corrected, test whether the correction remains effective and document any residual risk that the organisation has chosen to accept.
A cyber security control should be reviewed whenever a dependency that supports it changes, because the control may no longer work as designed even if its own settings remain unchanged. Dependencies can include identity services, cloud platforms, network equipment, backup arrangements, outsourced IT functions and business applications.
For example, changing an identity platform can affect authentication, administrator access and account removal processes. Moving an application to a different hosting arrangement may alter logging, network boundaries or backup responsibilities. These changes should trigger a targeted review of the controls that rely on them, rather than waiting for the next scheduled assessment.
Maintaining a simple record of control dependencies helps determine the review scope after a technology or supplier change. It should identify the responsible owner, the supporting service, the potential security impact of a change and the evidence needed to confirm that protection remains effective. This makes the review frequency responsive to the organisation’s actual technology environment.