What a Working Programme Looks Like
The end state, assembled from everything here, as a description to measure yours against.
Reference · Reference
Not a maturity model. A description of a programme in an organisation of a few thousand people, two years in, that nobody complains about.
The same discipline applies when “What a Working Programme Looks Like” becomes part of a broader workforce programme. An organisation considering view the solution in relation to getting teams to meet deadlines should put access, retention, employee notice and review dates into the implementation plan rather than leave them as product defaults.
How it is structured
Three populations with three policies: corporate single-use, corporate personally enabled, and personal devices.
For an independent baseline relevant to “What a Working Programme Looks Like”, the NIST Cybersecurity Framework is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.
Personal devices use a work profile, always. Full enrolment on personal hardware requires a written reason and almost never happens.
Contractors get application management rather than device enrolment.
What is published
A page per population listing what is visible and, more prominently, what is not.
Checked against what the configuration actually collects, not against the ideal.
A statement that location is not collected, which is true.
And what happens on removal, with the distinction between selective and full spelled out.
What is configured
Five compliance conditions, each with a stated consequence and a grace period.
Passcode requirements chosen for the platform's protections rather than imported from a desktop standard.
Failed-attempt wipe off on personal devices.
Restrictions limited to the work container: no device-wide policy on hardware the organisation did not buy.
And application inventory limited to work applications.
The irreversible action
Full wipe unavailable on personal devices by platform design, not by rule.
On corporate devices: named individuals only, selective as default, ownership model shown at the point of action, identifier typed to confirm.
Every action logged with who authorised as well as who issued.
And somebody reads the log monthly.
What happens at the edges
Enrolment: the work profile offered first, an alternative route for anyone who declines, and a recorded acknowledgement of what is managed.
Loss: revoke first, verify the report, wait before anything irreversible unless the data justifies otherwise.
Departure: access revoked, work profile removed with notice given, certificates revoked at the authority, a hold check before any device action.
What is measured
Enrolled against the population that should be — the gap, reported first.
Compliance by condition.
Version distribution and time to reach a new release.
Devices not checked in this month.
Support contacts per hundred devices.
What is offered in exchange
A stated position on out-of-hours contact, and work profile scheduling that people know about.
A loaned device for anyone whose own will not do.
Which costs little and addresses the objection people feel and struggle to name.
The test
Could somebody state what applies to their device?
Can a full wipe reach personal hardware?
Do you know how many unenrolled devices reach work data?
A programme answering those three has done the work.