ACTIVITIES

A.  Estimate overall device risk profile

Interview business owners, service desk leads and stakeholders and create a list of worst-case scenarios across the organization's device estate. Based on the way in which your organization issues, permits and uses devices, the list of worst-case scenarios can vary widely, but common issues include loss or theft of an unencrypted laptop, credential theft from a compromised handset, ransomware reaching a file share from a desktop, or an unmanaged personal device holding regulated data.

After broadly capturing worst-case scenario ideas, collate and select the most important based on collected information and knowledge about the core business. Any number can be selected, but aim for at least 3 and no more than 7 to make efficient use of time and keep the exercise focused.

Elaborate a description of each of the selected items and document details of contributing worst-case scenarios, potential contributing factors, and potential mitigating factors for the organization.

The final device risk profile should be reviewed with business owners and other stakeholders for understanding.

B.  Build and maintain assurance program roadmap

Understanding the main business risks to the organization, evaluate the current performance of the organization against each of the twelve Practices. Assign a score for each Practice from 1, 2, or 3 based on the corresponding Objective if the organization passes all the cumulative success metrics. If no success metrics are being met, assign a score of 0 to the Practice.

Once a good understanding of current status is obtained, the next goal is to identify the Practices that will be improved in the next iteration. Select them based on device risk profile, other business drivers, compliance requirements, budget tolerance, etc. Once Practices are selected, the goals of the iteration are to achieve the next Objective under each.

Iterations of improvement on the assurance program should be approximately 3-6 months, but a strategy session should take place at least every 3 months to review progress on activities, performance against success metrics and other business drivers that may require program changes.

ACTIVITIES

A.  Conduct periodic industry-wide cost comparisons

Research and gather information about endpoint security costs from intra-industry communication forums, business analyst and consulting firms, or other external sources. In particular, there are a few key factors that need to be identified.

First, use collected information to identify the average per-device security spend being applied by similar types of organizations in your industry. This can be done either top-down from estimates of total percentage of IT budget or headcount, or bottom-up by identifying the management, protection and support activities that are considered normal for your type of organization.

The next goal of researching costs is to determine if there are potential savings on the management, protection and support tooling that your organization currently licenses. When weighing the decision of switching vendors, account for hidden costs such as re-enrolling the fleet, retraining staff, or running two agents in parallel during migration.

Overall, these cost-comparison exercises should be conducted at least annually prior to the subsequent strategy session. Comparison information should be presented to stakeholders in order to better align the program with the business.

B.  Collect metrics for historic endpoint spend

Collect information on the cost of past device incidents. For instance, time and money spent reimaging and reissuing hardware after a compromise, replacement cost and data exposure from lost or stolen devices, productivity lost to support escalations, regulatory fines following an unencrypted loss, and one-off tooling purchases made in response to an incident.

Using the device risk categories and the respective prescribed roadmaps for each, a baseline security cost per device can be initially estimated from the costs associated with the corresponding risk category.

Combine the per-device cost information with the general cost model based on risk category, and then evaluate business units for outliers, i.e. sums disproportionate to the risk rating. These indicate either an error in risk evaluation or the necessity to tune the organization's program to address root causes for cost more effectively.

The tracking of endpoint spend should be done quarterly at the strategy session, and the information should be reviewed and evaluated by stakeholders at least annually.

ACTIVITIES

A.  Identify and monitor external compliance drivers

Gather the regulations, contractual obligations and industry standards that place requirements on the devices your organization issues. Common drivers include data-protection law where a lost device constitutes a breach, payment and health care standards that mandate encryption and access control on endpoints, and customer contracts that specify managed-device requirements for anyone touching their data.

For each driver, extract the specific obligations that land on a device rather than on the wider organization — full-disk encryption, screen lock and timeout, malware protection, patch currency, remote wipe capability, and retention of device logs are the usual set.

Assign an owner for each compliance driver and establish a lightweight review to catch changes. Standards and interpretations shift, and a control that satisfied an auditor two years ago may no longer be sufficient.

B.  Build and maintain compliance guidelines

Consolidate the obligations gathered above into a single set of guidelines expressed in terms the teams who build and manage devices can act upon. Auditors speak in outcomes; endpoint engineers need settings.

Cover the whole estate rather than just corporate laptops. Handsets, tablets, personally-owned devices under a bring-your-own scheme, contractor equipment and shared or kiosk devices all carry obligations, and the shape of those obligations differs by ownership model.

Publish the guidelines somewhere the relevant teams already work and review them at least annually.

ACTIVITIES

A.  Conduct periodic compliance audits of the estate

Move from confirming compliance at issue to confirming it continuously. Devices drift: users disable agents, defer updates indefinitely, or fall out of management when they are reimaged by a local administrator.

Audit against the internal standards rather than against the tooling's own notion of health, and sample devices directly rather than relying solely on the management console — a device that stopped reporting three months ago is the one you most want to look at.

Each business unit should undergo audit at least biannually, with the highest risk device tiers audited more often.

B.  Collect and control compliance evidence

Establish a repository of evidence sufficient to satisfy an external auditor without a scramble. Encryption status by device, patch currency over time, policy acknowledgements, exception records and wipe confirmations are the artifacts most commonly demanded.

Automate collection from the management platform wherever possible and retain evidence for the period your compliance drivers require. Evidence assembled by hand at audit time is expensive and tends not to survive scrutiny.

Report adherence to stakeholders at least quarterly, trending over time rather than reporting a single snapshot.

ACTIVITIES

A.  Conduct technical endpoint security awareness training

Offer the staff who build, deploy and support devices access to training that covers the fundamentals of endpoint security. Either internally-led or externally sourced training is workable, but the material must reflect the platforms your organization actually runs.

Cover the mechanisms that matter on a modern device: disk encryption and where its keys live, secure boot and hardware roots of trust, the privilege model of each operating system, how management agents enforce policy, and the common paths by which a device is compromised.

Aim to reach the whole endpoint and service desk population within a year, and refresh at least every two years as platforms change.

B.  Build and maintain technical guidelines

Assemble a set of reference guidelines for the teams who work on devices. These should cover the specific settings and procedures your organization expects rather than restating general advice available elsewhere.

Practical topics include how to enroll each platform, which baseline applies to which device tier, how to handle a device returned by a departing employee, and what to do when a user reports a device lost.

Try to keep the guidelines lightweight and up to date to avoid clutter and irrelevance. A short document that is current beats a comprehensive one that is eighteen months stale.

ACTIVITIES

A.  Establish role-based examination and certification

Introduce assessment so that competency is demonstrated rather than assumed. For the staff who build and manage devices, this can be a practical examination against your own baselines and tooling.

Tie certification to access. An engineer holding administrative rights over the fleet is one of the highest-privilege roles in the organization, and it is reasonable to require demonstrated competency before granting it and to review that competency periodically.

For general users, lightweight verification such as simulated phishing with follow-up training for those who need it is usually more informative than a test.

B.  Establish centralized guidance control

Bring the guidance material under central control with clear ownership, review cycles and version history, so that the organization can state with confidence what its current expectations are.

Distribute from a single authoritative source and retire superseded material actively. Stale guidance circulating in parallel with current guidance is a common cause of drift.

Measure whether guidance is reaching people and being used, and feed that back into the roadmap.

ACTIVITIES

A.  Build and maintain device-specific threat models

For each class of device the organization issues, build a lightweight model of how it could be attacked. The exercise does not require formal methodology at this level; a workshop and a page of notes per device class is enough to start.

Work through the ways a device is exposed. It is carried in public and can be lost or stolen. It joins untrusted networks. It runs software the user chose. It holds cached credentials and tokens that reach far beyond the device itself. It has physical ports, and it eventually leaves the organization.

Record for each threat what currently stands in the way. Many organizations discover at this point that a control they assumed was universal covers only part of the estate.

Review the models with the teams who manage each platform and refresh at least annually.

B.  Develop attacker profile from device usage

Characterize who would attack your organization through its devices and what they would want. The opportunist who resells a stolen laptop, the commodity malware operator seeking any foothold, and the targeted actor pursuing a named executive call for very different defenses.

Ground the profile in how devices are actually used. An organization whose staff travel to high-risk jurisdictions carries different exposure from one whose devices never leave a controlled office, even if the hardware is identical.

Document the profiles alongside the threat models so the two are read together.

ACTIVITIES

A.  Explicitly evaluate risk from unmanaged and third-party devices

Extend threat assessment to the devices your organization does not own but that nonetheless reach its data: personally-owned phones, contractor laptops, partner equipment and the hardware of acquired companies not yet integrated.

For each category, establish what is actually known about the device and what is merely assumed. Where assurance cannot be obtained directly, decide whether to reduce what the device can reach, require an intermediating control, or accept the residual risk explicitly and record who accepted it.

Reassess when the relationship changes. A contractor whose engagement is extended from three weeks to two years warrants a different answer.

B.  Elaborate threat models with compensating controls

Complete the mapping from each identified threat to the specific controls that mitigate it, and record the residual risk that remains after those controls are applied.

This mapping is what allows an organization to answer the question auditors and executives actually ask — not 'what controls do you have' but 'what happens if this occurs'. It also exposes controls that mitigate nothing in the current threat model and are candidates for retirement.

Maintain the mapping as controls change, and review residual risk with business owners at least annually so that acceptance is renewed deliberately.

ACTIVITIES

A.  Derive security requirements from business use

For each device class, work from how the device will be used to the security properties it must have. Start from the data the device will reach and the environments it will be carried into rather than from a generic checklist.

A short set of requirements per class is enough at this level. Typical entries include support for full-disk encryption with keys protected in hardware, the ability to enforce screen lock and remote wipe, a defined minimum period of vendor security updates, and compatibility with the organization's management platform.

Have the requirements reviewed by the teams who will support the device. A requirement that cannot be enforced with the tooling the organization owns is not yet a requirement.

B.  Evaluate security and compliance guidance for requirements

Draw on the compliance guidelines and threat models already produced to catch requirements that use alone would not surface.

Compliance drivers often mandate specific device properties, and the threat models will suggest others — a device class exposed to physical attack needs firmware protection and port control that an office desktop may not.

Consolidate into a single requirement set per device class so that procurement has one document to work from rather than several.

ACTIVITIES

A.  Build security requirements into supplier agreements

Carry the organization's device requirements into its contracts with hardware vendors, resellers, managed service providers and any third party whose staff use devices to reach your data.

The commitments worth securing in writing are the ones that are impossible to retrofit: a defined security update period with a stated end date, notification obligations when a firmware vulnerability is discovered, supply chain integrity assurances, and the right to audit a managed service provider's device estate.

For contractors and partners, specify the device standard required of anyone touching your data and the evidence they must be able to produce.

B.  Expand audit program for device requirements

Extend routine audit to cover whether devices in service actually meet the requirements specified for their class, closing the loop between what was specified and what was delivered.

Audit the supplier commitments too. A vendor's stated update period is only useful if someone notices when it lapses, and devices approaching end of support need to enter the replacement cycle before they stop receiving fixes.

Report findings into the strategy session so that requirement failures inform the roadmap rather than being handled solely as individual exceptions.

ACTIVITIES

A.  Maintain a list of recommended hardware and platforms

Publish the hardware and operating system versions the organization supports, and keep it short. Every additional platform multiplies the baselines to write, the agents to license and the expertise the support team must hold.

Base inclusion on the security requirements already specified — hardware root of trust, verified boot, a vendor update commitment that outlasts the intended service life, and support from the organization's management platform.

Record what is not supported as clearly as what is, and give the list an owner and a review cadence so it tracks vendor lifecycle announcements.

B.  Identify and promote secure configuration principles

Establish the handful of principles that every device build should honor, and make them explicit so that build decisions can be checked against something.

The durable ones are: encrypt storage by default with keys bound to hardware; run users without administrative rights; enable the platform's own protections rather than replacing them; prefer central management over device-local settings a user can change; and fail closed when the device cannot verify its own state.

Circulate the principles to the teams who build devices and use them as review criteria when a new build is proposed.

ACTIVITIES

A.  Build reference device configurations

Produce complete reference builds for each device class — not a document describing a build, but an actual provisioning configuration that yields a compliant device without manual steps.

Zero-touch provisioning is the goal: a device drawn from stock enrolls, applies its baseline, installs its required software and reports compliance without an engineer touching it. This removes the largest single source of configuration drift, which is human variation at build time.

Maintain the reference builds under change control with the same rigor applied to production infrastructure, and rebuild them regularly so they do not accumulate undocumented history.

B.  Validate usage of reference configurations

Verify that devices in service were in fact provisioned from the reference builds and continue to match them, rather than assuming that publishing a build ensures its use.

Devices acquired outside the standard process — bought on a departmental card, inherited through acquisition, or rebuilt locally after a fault — are the ones that will not match, and they are disproportionately represented in incidents.

Report the proportion of the estate provisioned from reference builds as a program metric, and route exceptions through the documented process rather than letting them accumulate silently.

ACTIVITIES

A.  Identify the protection perimeter of a device build

For each proposed build, document what it is expected to protect and where the boundaries lie. This is the device equivalent of an attack surface diagram and it need not be elaborate.

Record what runs with elevated privilege, what the device stores locally, what credentials and tokens it will hold, which networks it will join, which peripherals and removable media are permitted, and what remains accessible when the device is locked or powered off.

The exercise is most valuable where builds diverge from the standard. A build created for a specific team is exactly where an exception gets made quietly, and writing down the perimeter forces that exception into the open.

B.  Check the build against known security risks

Review each proposed build against the organization's threat models and configuration principles, working through the identified threats and asking what in this build addresses each one.

Concentrate on the properties that are hard to change later: whether encryption is enabled before first use rather than after, whether the user runs with administrative rights, whether recovery keys are escrowed, and whether the device can be wiped remotely once issued.

Record the review outcome with the build. Even an informal note stating who reviewed it and what was raised gives the next reviewer a starting point.

ACTIVITIES

A.  Develop data-level review of device builds

Deepen review to cover the data a build permits on the device and what happens to it under adverse conditions.

Trace specific data classes through the build. Where does regulated data land when a user opens an attachment? Is it in a managed application container or the general filesystem? What synchronizes to personal cloud storage? What survives a selective wipe, and what does the user retain if they leave the organization holding a personally-owned device?

These questions are answerable at design time and expensive to answer after a regulator asks them.

B.  Require reviews and audit build compliance

Make review mandatory for builds destined for the higher device risk tiers, and verify through routine audit that the requirement is being met rather than assuming it.

Audit both that reviews happened and that their conditions were implemented. A review that concluded 'approved provided disk encryption is enforced before first logon' is worth nothing if nobody checked that the condition was met.

Feed audit findings into the strategy session so systematic review failures are addressed as programme problems rather than individually.

ACTIVITIES

A.  Create review checklists from known requirements

Build a checklist per platform from the security requirements and baselines already defined, expressed as things that can actually be observed on a device.

Keep it to the settings that carry real weight rather than every line of a benchmark. Encryption enabled and keys escrowed, screen lock enforced, management agent present and reporting, security updates current within the defined window, no unexpected local administrators, and host protections enabled will identify most of the devices that need attention.

Have the checklist reviewed by the teams who support each platform, since they will know which settings are commonly disabled and why.

B.  Perform point review of high-risk devices

Sample devices from the higher risk tiers and check them against the checklist directly, rather than relying on the management console's own compliance view.

Checking the device itself matters because the console reports what agents tell it, and the devices of most concern are precisely those where the agent has stopped functioning, been removed, or is reporting a stale result.

Start with executive devices, administrator workstations and anything holding regulated data. Record findings and route them for remediation with an owner and a date rather than filing them as a report.

ACTIVITIES

A.  Customize assessment for organization-specific concerns

Extend automated assessment beyond benchmark settings to the configurations that matter specifically to your organization and would not appear in any published standard.

These are usually the interesting ones: the internal application that requires a weakened setting, the legacy certificate that must not be present, the departmental tool that creates a local administrator during install, or the specific configuration profile that a previous incident showed to be dangerous.

Maintain these custom checks with the same discipline as the baselines, since a check written in response to an incident three years ago may now be enforcing something obsolete.

B.  Establish release gates for device configuration

Define a configuration standard that must be met before a build or a significant policy change is released to the estate, and enforce it as a gate rather than a guideline.

Pilot a change against a representative sample and require the sample to meet the standard before wider release. Configuration changes are deployed to the whole estate at once and are correspondingly unforgiving of error.

Route audit findings into the strategy session, and treat repeated gate failures as a signal about the build process rather than about individual changes.

ACTIVITIES

A.  Derive test cases from known requirements

Turn the security requirements for each device class into tests that can actually be run, so that a requirement can be shown to hold rather than asserted.

Start with the controls the organization is most relying upon. If the risk profile rests on disk encryption protecting a lost laptop, the test is to attempt to read data from a powered-off device. If it rests on remote wipe, the test is to wipe a device that is offline at the moment of the request and observe what happens when it reconnects.

Document the expected result alongside each test so that a change in behavior after a platform update is noticed.

B.  Conduct penetration testing on the device build

Have a representative device tested by someone attempting to defeat its controls, working from a realistic starting position rather than with administrative access.

Useful scenarios at this level include an attacker with physical possession of a locked device, a user tricked into installing a malicious profile or application, and a device joined to a hostile network. The question in each case is what the attacker reaches and how far they travel.

Test a device built from the standard process rather than one prepared for the test, and record findings against the build so remediation lands in the reference configuration rather than on a single machine.

ACTIVITIES

A.  Employ organization-specific test cases

Generate test cases from your own threat models and abuse cases rather than a generic catalogue, so that testing addresses the paths that matter for your organization.

Where an abuse case describes a chain from device compromise to data loss, build a test that attempts the chain and establishes where it breaks. This produces findings expressed in business terms, which is what makes them actionable by people outside the security team.

Include the response process in scope. Testing whether a compromised device is detected, contained and remediated within the target time measures the whole system rather than the product.

B.  Establish a release standard for the fleet

Define the security testing that must pass before a build or major platform version is released to the estate, and hold the line on it.

Fleet releases are unusually risky because they are uniform: every device receives the same change at roughly the same time, and a defect is therefore present everywhere at once. A defined standard, applied to a pilot group before wider release, is the main protection against this.

Require audit evidence that the standard was met, and route exceptions through the documented process with a named approver.

ACTIVITIES

A.  Identify point of contact for device issues

Establish and publish a single obvious route for reporting a device problem, and make it work from a device the person no longer has.

This is a more literal requirement than it sounds. If the only way to report a stolen laptop is an intranet form reachable from a corporate device, the report will arrive hours late. A phone number, a monitored address reachable from any device, and a route through the service desk should all lead to the same place.

Publish the route where people will find it under stress — in onboarding material, on the back of the asset label, and in travel guidance.

B.  Create informal device response capability

Assemble a small group who can act when a device incident is reported, with the access needed to do something about it.

The capability that matters most at this level is the ability to revoke: to sign a user out of their sessions, reset credentials, and issue a wipe command. Many organizations discover during their first real incident that the person who takes the report cannot perform any of these and must find someone who can.

Write down who holds these permissions and how they are reached outside working hours. Device losses do not respect business hours, and the window that matters is measured in minutes.

ACTIVITIES

A.  Conduct root-cause analysis of device incidents

Investigate what allowed each significant incident to occur and what allowed it to matter, rather than closing on the immediate remediation.

The causes worth finding are usually structural: the device was outside management because it was rebuilt after a hardware fault, encryption was disabled by a profile deployed for an unrelated reason, or the token lifetime meant revocation took six hours to take effect. Each of these is a programme finding rather than an incident finding.

Route causes to the Practice that owns them and track them to closure. An analysis programme that produces recommendations nobody implements erodes willingness to participate.

B.  Collect and report device incident metrics

Instrument the incident process so that its performance can be measured and trended, and report the results into the strategy session.

The measurements that drive behavior are time from occurrence to report, time from report to containment, the proportion of incidents involving devices outside management, and the proportion involving devices that were known to be non-compliant beforehand. The last of these is often the most uncomfortable and the most useful.

Trend over time rather than reporting snapshots, and use the data to argue for the roadmap rather than to allocate blame.

ACTIVITIES

A.  Maintain an inventory of devices and their software

Establish and maintain an accurate inventory of the devices connected to your organization's resources, along with the operating system versions and installed software each carries.

Inventory is foundational because every other control is scoped by it. An organization cannot patch, assess or wipe what it does not know exists, and the devices missing from inventory are disproportionately those acquired outside the standard process.

Reconcile sources rather than trusting one. The management platform, the identity provider's device records, network access logs and the asset register will each know about devices the others do not, and the differences are the finding.

Establish a route for removing devices from inventory when they are retired, so that the record stays useful.

B.  Apply security updates to devices and their software

Establish a consistent process for delivering operating system and application updates to the estate, with a defined window by device risk tier.

Set the window from the risk tier rather than uniformly, and measure against it. Latency is the meaningful number: how long, in practice, between a fix becoming available and the estate having it. Most organizations discover their real latency is considerably longer than their policy states.

Handle the long tail deliberately. A small population of devices that never restart, are used intermittently, or belong to people who defer every prompt will account for most of the residual risk, and it needs an owner rather than a reminder.

ACTIVITIES

A.  Identify and deploy relevant device protection tools

Extend protection to the environment devices operate in, rather than treating the device as though it sits inside a trusted perimeter it left years ago.

The controls that matter for a roaming estate are those that travel with the device: protective DNS and web filtering that apply off the corporate network, host firewall policy enforced regardless of location, encrypted transport to internal resources without granting broad network access, and mobile threat defence on handsets.

Select on the basis of the threat models rather than product category, and verify each control functions when the device is away from the office, which is where it will be needed.

B.  Expand audit program for device hardening

Bring the hardening controls under routine audit so that their continued operation is verified rather than assumed, and tie device health to access.

The strongest available form of this is conditional access: a device that cannot demonstrate current patch level, active protection and expected configuration receives reduced access until it can. This converts hardening from a standard into an enforced precondition.

Audit should confirm both that controls are present and that they are effective — an execution control running permanently in audit mode is present but not protecting anything.

Report findings into the strategy session so that systematic weaknesses drive the roadmap.

ACTIVITIES

A.  Capture critical device health information

Identify the information required to establish the state of a device and ensure it is collected and retained centrally.

The core set is small: enrollment and management status, operating system and patch level, encryption state, protection agent status and version, last check-in time, assigned user, and physical location where that is known and lawful to collect.

Last check-in deserves emphasis because it is the field that identifies devices quietly falling out of management, and it is the one most often absent from reporting that focuses on devices currently connected.

Review the collected set with the teams who respond to incidents, since they will know which field they most often wish they had.

B.  Document procedures for typical device alerts

For the alerts a device estate routinely produces, document what they mean and what the recipient should do about them.

Cover the common ones: malware detected and quarantined, encryption disabled or suspended, device offline beyond a threshold, unexpected administrative account created, and management agent removed. For each, record the likely benign explanation as well as the malicious one, since most alerts have both.

Keep the procedures where responders work rather than in a separate repository, and review them when alert volumes change materially.

ACTIVITIES

A.  Expand audit program for device operational information

Bring the monitoring itself under audit, verifying that the telemetry the organization believes it has is actually arriving and is actually being watched.

Audit for gaps rather than for volume. The questions that matter are which devices are not reporting, which alert types have never fired in a period when they plausibly should have, and which alerts were raised and never actioned. A sensor that silently stopped reporting produces no alerts, which is easily mistaken for an absence of problems.

Verify retention meets the period required by the organization's compliance drivers and by realistic investigation needs, which are usually longer than default settings provide.

B.  Validate device retirement and data removal

Establish and verify the end-of-life process, so that devices leave the organization without leaving anything behind.

The sequence needs to be explicit and confirmed rather than assumed: revoke the device's certificates and its trust with the identity provider, confirm data removal appropriate to the ownership model, unenroll from management, remove from inventory with a recorded disposition, and retain evidence of secure disposal or return.

Audit the outcome rather than the intent. Reconciling devices marked retired against those still holding certificates or still appearing in identity records reliably finds devices that were collected in a drawer and never processed, and the same reconciliation catches devices belonging to people who left the organization months earlier.