In short
An endpoint security policy is the written rulebook for every device that accesses your organisation's data: which devices are allowed, the minimum protection each must run (EDR, encryption, updates, no standing admin rights), how removable media, phones and personal devices are handled, and how incidents are reported. Security consoles then enforce it as technical policies.
Get a quote for endpoint security policy
Tell us roughly how many users or sites you have and we will reply by email with options and a quote.
What an endpoint security policy is
The phrase has two meanings, and you need both.
The written policy is an organisational document. It sets the rules: which devices are in scope, who owns them, the minimum security every device must have and what staff must do (and must not do). It is approved by management, read by staff and shown to auditors, insurers and customers who ask how you protect data on laptops and phones.
The technical policies are the settings pushed to devices by your security tools. An EDR console holds prevention, detection, response, device control and firewall policies; a mobile device management (MDM) platform holds configuration and compliance policies. They are what make the written rules happen on every device, every day.
Problems start when the two drift apart: a document that promises encryption on every laptop while three were not enrolled, or a console blocking USB drives that the policy says staff may use. The aim of this page is to help you write a policy that can be enforced and evidenced, clause by clause.
If you are starting from scratch, read our endpoint security best practices first; the policy is where those practices become rules.
Decisions to make before you write it
A policy is only as clear as the decisions behind it. Settle these first:
- Scope: laptops, desktops, servers, virtual machines, phones and tablets, and whether that includes personal devices. Our guide to what an endpoint is helps you list them.
- Ownership models: company-owned only, or company-owned plus BYOD with lighter controls for personal devices.
- Data: which information is sensitive enough that it must stay off unmanaged devices, removable media and personal cloud storage.
- Ownership of the policy: who approves it, who maintains it and who can grant exceptions.
- Frameworks you must meet: Cyber Essentials, UK GDPR's security principle, customer contracts or insurance questionnaires. Our endpoint security compliance guide maps these to controls.
- Who acts on alerts: an in-house team, an IT provider or a vendor's managed detection and response service. The policy should name the role, not just the tool.
The NCSC's Device Security Guidance is a sound, vendor-neutral basis for most clauses, and our summary of the NCSC Device Security Guidance maps its sections to the pages on this site.
Sample endpoint security policy outline
Use this outline as a starting point. Each row is a section of the written policy, what it typically requires, and how the requirement is usually enforced and evidenced. Adapt the requirements to your risk and size; a ten-person firm and a regulated organisation will set different bars.
| Policy section | What it typically requires | How it is enforced and evidenced |
|---|---|---|
| 1. Purpose and scope | Which devices, users and data the policy covers, including contractors and personal devices | Device inventory from your EDR and MDM consoles |
| 2. Roles and responsibilities | Policy owner, IT or provider responsibilities, user responsibilities, who approves exceptions | Named roles; exceptions register |
| 3. Approved devices | Only approved, supported devices and operating systems may access organisational data; unsupported versions are removed from use | MDM enrolment and compliance rules; conditional access |
| 4. Secure configuration | Devices are built to an agreed baseline: unused software removed, auto-run disabled, screen lock set, local firewall on | Baseline profiles; see endpoint hardening |
| 5. Malware protection, detection and response | Approved endpoint protection with EDR on every in-scope computer, tamper protection on, alerts reviewed | EDR coverage report; see endpoint detection and response |
| 6. Updates and patching | Operating system and application updates applied within set timescales; high-risk fixes prioritised | Patch compliance report; see patch management process |
| 7. Encryption | Full disk encryption on laptops and desktops; recovery keys held centrally | Encryption status report; see full disk encryption |
| 8. Administrative rights | No standing local admin for everyday accounts; elevation by approved process; separate admin accounts for admin work | Privilege management logs; see endpoint privilege management |
| 9. Software | Only approved applications may be installed or run; a process to request new software | Application control; see application whitelisting |
| 10. Removable media and peripherals | Which USB storage and peripherals are allowed, read-only or blocked; encryption of permitted media | Device control policy and audit; see USB device control |
| 11. Mobile and personal devices | Minimum OS version, screen lock, work data separation, mobile threat protection | MDM or app protection policies; see mobile threat defence |
| 12. Network and remote access | Access to internal services via approved remote access only, with MFA and a healthy device | Conditional access; see zero trust endpoint security |
| 13. Logging and monitoring | Security events collected from devices and reviewed | EDR or XDR console; see extended detection and response |
| 14. Incident reporting | How staff report a suspected compromise, lost device or suspicious message, and how quickly | Reporting route; response plan; see how to prevent ransomware attacks |
| 15. Lost, stolen and leaving | Report loss promptly; remote lock or wipe; device and access returned when someone leaves | MDM actions; leaver checklist |
| 16. Exceptions | How a temporary exception is requested, approved, time-limited and reviewed | Exceptions register with expiry dates |
| 17. Review | Policy reviewed at least yearly and after significant incidents or changes | Version history and approval record |
Keep the document short enough that people read it. Detailed settings (which device classes are blocked, which applications are approved) belong in a technical standard or the console itself, referenced from the policy, so they can change without re-approving the whole document.
Not sure which option fits? Ask us
Tell us what you need and we will recommend the right option for your organisation, with a quote.
Sample clauses you can adapt
Clear, testable wording makes a policy enforceable. A few examples in the style that works well:
- All organisation-owned laptops and desktops must run the approved endpoint protection and EDR agent, which users must not disable or remove.
- Devices must have full disk encryption enabled before they are issued, and recovery keys must be stored in the approved management console.
- Everyday user accounts do not have local administrator rights. Tasks that need elevation are requested through the approved privilege management tool.
- Only removable storage issued by IT may be written to. Other USB storage devices are blocked or read-only.
- Personal phones may access email and collaboration apps only through the approved apps and only while the device meets the minimum security requirements.
- Suspected loss, theft or compromise of any device that holds or accesses organisational data must be reported to IT straight away.
- Exceptions must be approved by the policy owner, recorded and reviewed before they expire.
Each clause names something you can check. If you cannot think how you would prove a clause is being followed, rewrite it or add the control that would let you.
From written policy to technical policy
Once the document is agreed, translate it into the consoles that enforce it. In most endpoint platforms that means a set of policies assigned to groups of devices:
| Technical policy | Implements policy section | Typical settings |
|---|---|---|
| Prevention policy | 5 | Malware and exploit protection levels, behavioural protection, tamper protection, exclusions |
| Detection and response policy | 5, 13 | What is logged, automated responses such as isolation, who is alerted |
| Device control policy | 10 | Allowed, read-only and blocked device classes; approved devices by vendor, product or serial |
| Firewall policy | 4, 12 | Host firewall on, rules by location or network |
| Application control policy | 9 | Allow or block rules, audit mode, request process |
| Patch or vulnerability policy | 6 | Scan schedule, deployment rings, deadlines by severity |
| Encryption policy | 7 | Enforce encryption, key escrow, recovery process |
| MDM compliance policy | 3, 11, 12 | Minimum OS, passcode, encryption, jailbreak or root detection, compliance feeding conditional access |
Three habits keep the two in step. First, introduce new restrictions in audit or detect-only mode, review what would have been blocked, then enforce. Second, record every exclusion and exception with a reason and an owner. Third, use the console's reports (coverage, encryption status, patch compliance, device control events) as the evidence for each clause; they are what an auditor or insurer will ask for. Our EDR deployment guide covers how to roll policies out in stages.
Is endpoint security policy the right fit for you?
We will check it against your systems and requirements and recommend the right option.
Keeping the policy alive
A policy written once and filed is worse than none, because it gives false confidence. Build in:
- A review cycle: at least yearly, and after a significant incident, a change of platform or a new framework requirement
- Coverage checks: compare your HR or asset list with the devices actually reporting to each console, so new and forgotten devices are caught
- Exception expiry: time-limited exceptions that are reviewed, not permanent ones that are forgotten
- Staff awareness: a short summary of what the policy means for users, given at induction and when it changes
- Testing: occasionally confirm that a blocked USB drive is blocked, that an unencrypted laptop is flagged, and that alerts reach the right person
How we help
We supply several endpoint security platforms, so we can help you write a policy that matches what your tools can actually enforce, rather than the other way round. We can:
- Review your current policy, or the lack of one, against your devices, your frameworks and the NCSC guidance
- Help draft the written policy and the technical standard behind it
- Recommend tools that close the gaps, from EDR and device control to privilege management and encryption, with pricing confirmed at quote
- Help configure the console policies and the reports you will use as evidence
Contact us to talk through an endpoint security policy for your organisation.
How Forever Systems helps with endpoint security
We are an independent UK IT and cyber security provider. We supply and support endpoint security from several vendors, so we can recommend what fits your devices, your people and your budget rather than one vendor's answer to everything.
- Start with what you have: we can review your current antivirus, EDR and Microsoft 365 licences before suggesting anything new
- Vendor-aware advice on EDR, XDR and managed detection and response, including CrowdStrike, SentinelOne, WatchGuard, Bitdefender, Sophos and Check Point Harmony
- Deployment help: planning a rollout, replacing an existing product and setting sensible policies for device control, encryption and patching
- Policies and compliance: we help you map your controls to Cyber Essentials and the NCSC's device guidance
- Ongoing support options, such as policy tuning, renewals and regular reviews, agreed and confirmed at quote
We work with businesses, schools, charities and public sector organisations. Tell us about your devices and we will suggest a sensible next step.
Frequently asked questions
What is an endpoint security policy?
An endpoint security policy is the set of rules for every device that accesses an organisation's data, such as laptops, desktops, servers and phones. It sets which devices are allowed, the minimum protection each must have and what users must do. The term is also used for the technical policies a security console pushes to devices to enforce those rules.
What should an endpoint security policy include?
Most policies cover scope, roles, approved devices, secure configuration, malware protection and EDR, updates, encryption, admin rights, approved software, removable media, mobile and personal devices, remote access, logging, incident reporting, lost devices and leavers, exceptions and review.
Is there a sample endpoint security policy I can use?
This page includes a sample outline with the sections most organisations need and example clauses you can adapt. Treat it as a starting point and set the requirements to match your risk, your frameworks and what your tools can enforce.
How often should an endpoint security policy be reviewed?
At least once a year, and also after a significant incident, a change of security platform, a new compliance requirement or a big change in how people work, such as introducing personal devices.
Does Cyber Essentials need a written endpoint security policy?
Cyber Essentials focuses on the technical controls on in-scope devices: firewalls, secure configuration, security update management, user access control and malware protection. A written policy that matches those controls makes the assessment easier to answer consistently. Our Cyber Essentials site explains the requirements.
Still have a question about endpoint security policy?
Ask us and a member of our team will reply by email.