How to decide whether an app belongs on a government phone
App approval is usually a yes or no made by whoever was asked. A repeatable assessment takes about twenty minutes and produces a decision you can defend.
Somebody asks for an application to be added to the managed catalogue. The request lands with whoever is available, who looks at it for a few minutes and forms a view.
That is the process in most organisations, including well-run ones. It produces inconsistent decisions, no record of why, and no way to revisit a decision when the application changes — which it does, silently, every few weeks.
Here is a version that takes about the same amount of time and produces something defensible.
1. What data does it touch?
Start here, because it determines how much the rest matters.
An application that never sees organisational data — a calculator, a torch, a transit app — needs almost no scrutiny. An application that reads mail, contacts, files, location or the camera needs all of it.
Be specific: not “it handles documents”, but which documents, from where, stored where, and for how long.
2. What permissions does it request, and why?
Look at the actual permission set rather than the description. The question is not whether each permission is plausible but whether it is necessary for what the application does for you.
Contacts access is the one to look at hardest. An application granted contacts access reads the entire address book at once, which on a government handset is a more sensitive dataset than most people classify it as.
Location, microphone and camera permissions on an application with no obvious need for them are worth a direct question to the vendor.
3. Who is the publisher, actually?
Not the brand on the listing — the entity behind it.
- Which company publishes it, and in which jurisdiction?
- Is it owned by another company, and where is that one?
- Is the development team in the same place as the corporate entity?
- Does the privacy policy name a real entity with a real address?
None of these is disqualifying on its own. All of them belong in the record, because the question “where could this data be compelled to go” is answered by corporate structure, not by hosting region.
4. Where does the data go?
The privacy policy will tell you more than the marketing page. What you are looking for:
- Named categories of data collected, not “usage information”
- Whether data is shared with third parties, and which
- Analytics and advertising SDKs embedded in the application
- Data retention periods
- Whether the data is used for training or product improvement
Embedded third-party SDKs are the part that surprises people. An application from a reputable publisher can still ship a component that transmits device and usage data to an advertising network, and that component is a supply chain you did not evaluate.
5. Does it support management?
For anything handling organisational data, this is close to decisive:
- Does it support managed app configuration, so settings are applied at deployment rather than typed by users?
- Can organisational data inside it be wiped selectively?
- Does it respect managed-app boundaries, so data cannot be copied into unmanaged applications?
- Does it support your identity provider, with conditional access applying?
- Is there a business or enterprise distribution channel, or only the public store?
An application that handles sensitive data and supports none of this is not really deployable, however good it is.
6. What happens when it updates?
Applications change. A permission that was not requested at approval can appear in a later version, an SDK can be added, and ownership can change hands entirely.
The practical control is to pin approved versions where the platform allows it, to review anything in the sensitive tier annually, and to watch for ownership changes on the applications that matter most. That last one is a genuine risk: a small utility with a large install base changing hands is a well-established way for something unwanted to arrive inside an existing trust relationship.
Making it a process
Three tiers is enough for most organisations:
Tier 1 — no organisational data. Approve on a light check. Record the decision.
Tier 2 — touches organisational data. Full assessment against the six questions above. Requires managed configuration support. Annual review.
Tier 3 — sensitive data or elevated access. Everything in tier 2, plus a named business owner, a documented data flow, and an explicit decision by someone with authority to accept the risk.
Record the decision, the date, the version assessed and the reason. The record is the point — it is what lets you answer an assessor, revisit a decision when something changes, and avoid making the same argument twice.
The one that gets missed
The applications already installed. Most catalogues were assembled before anyone had a process, and nothing triggers a review of an application that is already there.
Export the list of what is actually deployed across the fleet, sort by install count, and work down. The first pass is uncomfortable and it is the highest-value hour available.