END / END-04
Application, device and local-privilege control
Restrict executable software, usable peripherals and privilege elevation on sensitive devices. The service also governs exceptions so protection does not prevent legitimate work.

WHEN IT HELPS
A focused response
to a defined need.
Exposed industrial or administrative workstations, unauthorised software, data movement through USB drives or a need to limit installation without removing useful autonomy.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Software inventory
- usage observation
- allowlisting
- device restrictions
- controlled elevation
- signed rules
- pilot
- emergency and maintenance procedures
- logging
Deliverables
- Execution and device policies
- exception catalogue
- approval procedures
- pilot results
- support guide
- rollback mechanisms
Acceptance evidence
Approved applications work; unauthorised test execution is denied; device use follows policy; exceptions are traceable and limited; emergency mode is validated.
DELIVERY
How the work is structured.
Approach
Inventory versions and applications; define policies; test on a representative group; deploy; verify coverage and exceptions; organise maintenance.
Prerequisites & responsibilities
Customer: inventory, deployment tools, support, application owners and windows. Provider: policies and integration; alert handling only if included.
Scope factors
Devices, OSs, compatibility, existing tools, policies and deployment effort. Subscriptions, daily management and SOC coverage are priced separately.
Questions to clarify
Which applications must always work? Do suppliers use removable media? Who approves an urgent exception?
IMPORTANT BOUNDARIES
A blanket ban without an inventory can halt operations. These controls complement EDR and DLP but do not reproduce all their functions.
Unsupported systems, exclusions and operational gaps are made explicit. Regression tests, fallback and response ownership are part of delivery.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
An accounting department regularly installs unapproved tools. Project: move from observation to application allowlisting with a request catalogue. Target outcome: better-controlled execution without preventing necessary updates.
Scenario 02
A workshop transfers files through USB media. Project: authorise selected devices and establish a controlled transfer process. Target outcome: fewer untracked exchanges; technically incompatible equipment is handled separately.
Technology and reference context
Examples: native operating-system application control and privilege/device-management solutions, subject to compatibility.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.
