How to use this
The template is written to fit on one page, because a policy nobody reads protects nothing. Replace the text in square brackets. Delete what does not apply. It is a starting point from people who work on this problem, and it is not legal or compliance advice.
Two things make a policy like this work in practice.
- Name an approved place to run apps before you publish it. A rule that says “not there” without saying “here” pushes apps to personal accounts.
- Keep registration to five minutes. If listing an app is harder than building it, people will skip it.
The template
1. Scope
This policy covers any application built by [Company] staff, with or without AI coding tools, that is used by more than one person or that reads [Company] data. It does not cover one-off analysis run on a person’s own machine.
2. Every app has an owner
Each app has one named owner who is a current employee. The owner is responsible for the app’s access list, its data and its retirement. When an owner changes role or leaves, their manager names a new owner within [10] working days or the app is switched off.
3. Every app is registered
Before an app is shared, the owner records it in [the app catalog]. The record holds the app’s name, its owner, what it is for, who may use it, and which data it reads.
4. Apps run in approved places only
Apps run only on [approved platform or platforms]. Apps must not be hosted on personal accounts, on free tiers of public hosting services, or on a staff laptop that others connect to.
5. Access is by company sign-in and by group
Every app requires sign-in through [identity provider]. Access is granted to groups, not to individuals, and the owner chooses the smallest group that needs the app. No app that reads [Company] data may be reachable without sign-in.
6. Data access is read-only by default
Apps read production data through connections that [IT or the data team] has registered. Connections are read-only unless a written exception exists. Apps do not copy production data into their own storage beyond what they need to run.
7. Builders do not hold production credentials
Database passwords, API keys and tokens are supplied to the app by the platform when it runs. They are not written in code, not stored in files beside the code, and not pasted into an AI coding tool.
8. Uploaded files are data
Where an app runs on files that a person uploads, such as spreadsheets or exported reports, those files are treated as the system they came from. The owner records where each file comes from. Uploads are logged, and old versions are kept for [period] and then deleted.
9. Code is checked before it is shared
Each version of an app is scanned for leaked secrets and for dependencies with known vulnerabilities before it goes live. A version that fails the scan is not deployed.
10. Apps reach only what they need
Apps may make outbound connections only to destinations that [IT] has approved.
11. Activity is recorded
The platform records who deployed each version of each app and when. Records are kept for [period].
12. Apps are reviewed and retired
[IT] reviews the catalog every [quarter]. An app that nobody has used for [90] days is switched off after notice to its owner. An app without an owner is switched off.
13. Exceptions
Exceptions are requested from [role], recorded with a reason and an end date, and reviewed when they expire.
What to decide before you publish it
| Decision | Why it matters |
|---|---|
| The approved place to run apps | Section 4 is empty without it. This is the decision most companies have not made. |
| Who registers data connections | Sections 6 and 7 depend on a person or team who holds the credentials so that builders do not. |
| Where the catalog lives | A spreadsheet works for ten apps. It stops working when nobody updates it. |
| What counts as unused | Section 12 needs a last-used date for each app, which means something has to measure it. |
Where intrium fits
intrium is being built to be the approved place in section 4 and to make sections 3, 5, 7, 9, 10 and 11 the default instead of a rule people have to remember: a catalog with a named owner and a last-used date, access by Okta or Google group, credentials the builder never sees, a scan on every deploy, limited outbound traffic and an audit log. It is pre-launch. The policy is useful with or without it.