How should organisations build a practical security programme when teams are remote, hybrid, and using different devices?

Start with a clear inventory of the business, the people, the locations, and the data that needs protection. Then shape policies around how the company actually works, not how you wish it worked. A security programme is easier to adopt when it fits the organisation’s culture, work patterns, and risk exposure, because people are more likely to follow controls that feel realistic and relevant.

Build the programme around real work patterns, not idealised ones

A practical security programme starts with the organisation as it exists: who works where, what devices they use, which locations are trusted, and where sensitive data actually moves. That matters because remote and hybrid work increases variation in endpoint trust, network exposure, and supportability, so controls have to survive inconsistent environments instead of assuming one corporate perimeter.

For mixed-device workforces, the programme should separate the protection goal from the implementation choice. The goal is to reduce loss of control over access, data, and device posture; the implementation may vary by role, device ownership, or business unit. That approach avoids brittle rules that look strong on paper but fail when teams need practical exceptions.

Practicality is not a soft requirement. If the policy is too rigid for the way people actually collaborate, they will route around it, which creates shadow processes and weaker visibility. A good programme therefore treats operating reality as a design constraint, then uses controls that fit the most common work patterns first.

Translate the environment into a manageable control set

Once the organisation has mapped its people, places, devices, and data, the next step is to turn that map into a small number of enforceable control decisions. The strongest programmes typically group users by risk and context, then apply different levels of access, data handling, device requirements, and monitoring to each group rather than issuing one policy for everyone.

That means deciding what must be consistent everywhere, such as data classification, minimum authentication expectations, logging, and incident reporting, versus what can flex for business productivity, such as approved device types, collaboration tools, or travel exceptions. Clear boundaries help because remote and hybrid operations usually fail at the seams between teams, not inside a single control.

Control selection should also account for support burden. If a security measure requires constant manual intervention from IT or from end users, adoption falls quickly in distributed workplaces. The programme should favour controls that are easy to explain, easy to verify, and difficult to bypass, especially for high-impact data and administrative activity.

Design for adoption, visibility, and continuous adjustment

A security programme in a remote and hybrid environment needs to be measured by behaviour, not just by policy publication. Adoption improves when controls are predictable, when exceptions are limited and documented, and when employees understand why a rule exists in their working context. The more a control clashes with daily work, the more likely people are to avoid it or create workarounds.

That is why visibility is as important as restriction. Teams should be able to see where sensitive data lives, who can reach it, which devices are compliant, and where exceptions are accumulating. Without that operational picture, the programme becomes reactive: controls are added after incidents, rather than tuned to actual exposure.

Current guidance from ISO/IEC 27002:2022 Information Security Controls and the NIST Cybersecurity Framework 2.0 both support this kind of iterative structure: understand context, choose proportionate controls, and review whether they are actually working as conditions change.

Risk and Threat Considerations

Remote and hybrid working expands the organisation’s attack surface because it increases the number of endpoints, networks, and user contexts that can expose data or access. The main risk is not remote work itself, but the inconsistency it introduces, particularly where unmanaged devices, weak local security, or poorly governed exceptions create openings for compromise or data loss.

Failure mechanism: Security breaks when policy assumes uniform control, but the workforce is spread across different devices, locations, and support conditions. Attackers and accidental misuse both benefit from that gap because they can target the least visible endpoint, the weakest access path, or the exception that was never fully reviewed.

Impact: The result can be unauthorized access, data exposure, reduced monitoring quality, and control drift across teams. Over time, that erodes trust in the programme itself, because the organisation has rules that sound strict while practical enforcement remains uneven.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
ISO/IEC 27001:2022	A.5.9 — Inventory of information and other associated assets	Remote and hybrid programmes depend on knowing people, devices, locations, and data assets.
	A.5.10 — Acceptable use of information and other associated assets	Different device and work patterns require clear, usable rules for how assets may be used.
	A.8.1 — User endpoint devices	Mixed-device workforces create endpoint trust and support variability that this control addresses.
Recommendation — Maintain an accurate inventory of assets and data to scope controls to real working conditions. Define acceptable-use rules that fit common remote and hybrid work behaviours. Set baseline requirements for endpoint devices used to access business information.
NIST CSF 2.0	GV.OC-01 — Organizational Context	The programme must be built around the organisation's actual people, places, devices, and data.
	ID.AM-01 — Physical devices and systems are inventoried	Device diversity and remote use require an inventory to understand exposure and trust.
	PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited	Distributed work needs consistent access governance across users and devices.
Recommendation — Establish organisational context before selecting security controls. Inventory devices and systems that participate in remote and hybrid work. Manage access lifecycles so remote users only retain appropriate access.

Practitioner Guidance

What to prioritise: Start with the few control decisions that materially reduce exposure across the widest range of work patterns, especially device trust, data handling, and exception management. Do not begin with a long policy rewrite if the organisation cannot yet describe who needs access to what, from where, and on what kind of device.

What to verify: Check whether every major workforce segment has a clear control path that matches its actual operating model, including contractors, travellers, and BYOD users where applicable. If a group depends on exceptions to do normal work, the programme needs adjustment, not just more enforcement.

Practitioner takeaway: The best programme is the one the business can actually follow, because security in distributed work fails fastest when controls ignore real working conditions.