What Should an SME Cyber Security Policy Include?
An SME cyber security policy should define how the business protects its information, systems and devices from threats. It should cover access controls, secure working practices, incident reporting, staff responsibilities, data protection, backups, supplier risks and regular policy reviews.
An SME cyber security policy should set out the organisation’s security objectives, the rules that apply to its technology and information, and the responsibilities needed to enforce those rules. It should be practical enough for employees to follow, specific enough for technical teams to implement, and proportionate to the organisation’s size, systems, data and risk profile.
1. Purpose, scope and objectives
Begin by explaining why the policy exists and what it is intended to protect. The scope should identify the people, locations, devices, applications, networks, cloud services and information covered. It should include employees, contractors, temporary workers and other users who can access business systems, whether they work from company premises or another location.
Objectives might include maintaining the confidentiality, integrity and availability of business information, meeting contractual and legal obligations, reducing avoidable risk, and ensuring that security decisions support business operations. Defining the scope prevents important systems or user groups from being excluded accidentally.
2. Governance and accountability
The policy should name the person or role accountable for information security. In a smaller organisation, this may be a director or senior manager supported by an internal IT lead or external IT provider. It should also explain who approves changes, who owns particular systems and who is responsible for making sure requirements are implemented.
Responsibility should not sit entirely with the IT function. Management remains responsible for accepting or reducing business risk, while system owners should understand the importance of the information they manage. Employees should know which rules apply to them and where to obtain guidance.
3. Risk assessment and proportionate controls
A useful policy links security requirements to identifiable risks rather than listing controls without context. It should describe how the organisation assesses threats, weaknesses, potential business impact and the likelihood of an incident. This assessment can consider financial loss, operational disruption, legal exposure, damage to confidential information and harm to customers or suppliers.
The policy should explain how risks are recorded, who decides which risks are acceptable, and how actions are prioritised. A small business does not need the same control framework as a highly regulated enterprise, but it does need a documented rationale for important decisions and a way to identify when its risk profile changes.
4. Information and asset ownership
The document should establish how the organisation keeps track of important hardware, software, cloud platforms and information repositories. Each significant asset should have an owner who understands its purpose, users, dependencies and security requirements.
Information should be classified according to its sensitivity and business value. The policy can define categories such as public, internal, confidential and highly confidential, then state what handling requirements apply to each category. This provides a consistent basis for deciding who may use information, where it may be stored and how it may be shared or disposed of.
5. Technical security standards
The policy should refer to the minimum technical standards expected across the business. These may include supported operating systems, security updates, endpoint protection, secure configuration, encryption where appropriate, network protection and controls for cloud services. Rather than relying on informal assumptions, it should state how standards are approved and what happens when a system cannot meet them.
It should also distinguish between mandatory requirements and recommended good practice. For example, a business may require a supported operating system and approved security software, while treating a particular configuration improvement as a prioritised action. This distinction makes the policy easier to apply and audit.
6. Identity, authentication and privileged activity
Although detailed access procedures may sit in a separate standard, the main policy should establish the principles governing digital identities. These include using individual accounts, limiting administrative privileges, protecting authentication information and removing unnecessary permissions when a person’s role changes.
Privileged activity deserves specific attention because administrator accounts can affect large parts of the environment. The policy should require appropriate approval, monitoring and review of privileged access, while avoiding shared accounts wherever individual accountability is required.
7. Workforce expectations and acceptable use
Employees need clear rules for using company technology and information. The policy should cover the permitted use of business systems, restrictions on unauthorised software and services, handling of confidential material, use of removable media, and the circumstances in which business information may be transferred or accessed.
It should explain that security requirements apply to ordinary working practices as well as technical administration. Staff guidance should be concise, understandable and relevant to actual job roles. Separate procedures can provide detailed instructions, but the policy should make clear that ignoring security requirements may create business and disciplinary consequences.
8. Third-party and cloud services
Where suppliers, contractors or hosted platforms can access systems or information, the policy should define the minimum due diligence required before approval. Relevant considerations include the supplier’s security controls, contractual responsibilities, data location, access arrangements, resilience, subcontractors and process for ending the relationship.
It should also identify who reviews supplier risk and how exceptions are documented. A business should know which external services support important operations and avoid introducing a service simply because it is convenient without considering its security implications.
9. Monitoring, evidence and enforcement
A policy is more effective when the organisation can demonstrate whether it is being followed. Include provisions for appropriate logging, security monitoring, compliance checks and management reporting, while ensuring that monitoring is lawful and communicated clearly to users.
The policy should define how non-compliance is handled. Minor issues may require guidance or corrective action, whereas deliberate or serious breaches may require escalation under the organisation’s disciplinary or contractual processes. Records of decisions, approvals and exceptions provide useful evidence during audits and reviews.
10. Exceptions and risk acceptance
Some systems may be unable to meet a standard immediately. A formal exception process should record the requirement being waived, the reason, the affected assets, the risks created, any compensating safeguards, the person approving the exception and its expiry or review date.
Exceptions should be temporary wherever possible. Without an owner and review point, a short-term workaround can become a permanent weakness that is overlooked during future security assessments.
11. Policy maintenance and testing
Include document control information such as the owner, approval date, version, review interval and change history. Reviews should also be triggered by significant changes to systems, business activities, legal requirements, suppliers or the threat environment.
The organisation should test whether the policy works in practice. This may involve reviewing configurations, checking records, sampling user understanding, examining exceptions and carrying out exercises against relevant procedures. Findings should lead to assigned actions rather than being recorded without follow-up.
A well-written SME cyber security policy is therefore a governing document, not just a list of technical instructions. It should connect business risks with clear responsibilities, minimum standards, evidence of compliance and a controlled method for dealing with exceptions. Detailed procedures and technical standards can sit beneath it, allowing the main policy to remain understandable while the supporting controls can be updated as the organisation develops.
An SME cyber security policy should include a clear process for reporting suspected incidents. Staff should know what to report, such as a suspicious email, lost device, unexpected account activity, malware warning or accidental disclosure of information, and where to report it. The policy should instruct users not to delete messages, reset affected devices or investigate beyond their role, as these actions may remove useful evidence.
It should also define how reports are assessed and escalated. The responsible person should determine the systems, information and users affected, contain the immediate risk, record key decisions and involve management when the incident could disrupt operations or create legal, contractual or regulatory consequences. Afterward, the organisation should review what happened and update its controls or guidance where necessary.
Need Help Reviewing Your SME Cyber Security Policy?
If your current SME cyber security policy is outdated, incomplete or difficult for staff to apply, S2 Technology Group can help review its coverage and practical implementation. Contact us to discuss the areas that need attention and identify suitable next steps for your organisation.