Technology Standard
A technology standard states required or approved technology choices and practices for a defined purpose. NIST’s broader definition includes requirements, specifications, guidance, and characteristics used consistently for fitness of purpose. Here, an internal standard is a rule whose mandatory scope and authority are explicit; advisory guidance should be labeled separately.
Making the rule usable
A product name alone leaves teams guessing where it applies and who can change it. Record the following information together with the authority that makes the rule binding.
- The decision it governs. Relational databases for transactional data is a standard; use PostgreSQL without saying for what is a product endorsement that will be applied to cases nobody considered.
- Scope. Which systems, which environments, and whether it applies to new work only or also to existing systems at their next major change.
- Status, from a small fixed set, described below.
- An owner who maintains the standard and routes decisions. Record separately who has authority to approve departures, within which scope and limits; ownership alone does not confer that authority.
- Review conditions. Set a review date and triggers such as changed support, risk, or requirements. GOV.UK’s Open Standards principles call for periodic updates and evaluation of new compulsory-standard versions. This is a public-sector policy example, not a universal private-sector obligation.
- A response to unmet requirements. State whether departures are permitted and how they are authorized. DORA recommends a tooling exception process; GOV.UK’s policy requires an exemption request and case-by-case assessment. Where departure is not allowed, rejection, suspension, or redesign remains necessary. An internal exception cannot waive a binding external obligation.
An example technology status model
| Status | Meaning | What a team does |
|---|---|---|
| Preferred | Default option with a stated support commitment | Uses it within delegated authority and all applicable controls; preference alone does not grant access, funding, or deployment approval |
| Permitted | Approved alternative within a stated scope and support arrangement | Records its fit and satisfies any required approvals; the label alone does not settle support or compatibility |
| Contained | No expansion beyond explicitly authorized existing use | Maintains the approved controls and review or expiry conditions. Continued use needs valid authority, not merely the status label |
| Retiring | Scheduled removal or replacement | Plans and verifies transition before removal. Any continued use beyond the deadline needs authorized reassessment. See deprecation and vendor support lifecycle |
These labels are a proposed internal model, not an exhaustive standard lifecycle. Define their scope and transitions locally. Containment can limit spread while migration is evaluated, but it must not turn an expired exception into permanent permission. Enduring approved alternatives need continuing ownership and review; temporary departures need an exit condition or expiry.
DORA recommends a tooling baseline broad enough to meet most needs. Frequent exceptions can reveal missing capabilities, support gaps, or transition constraints. Review those reasons before deciding whether to broaden the baseline or keep a narrower choice.
Standard, guideline, and reference architecture
An internal standard binds within its declared authority and scope. A guideline advises, while any separate mandatory requirement still applies. A reference architecture describes reusable components, relationships, decisions, and conditions for a recurring problem. GOV.UK’s standards-based profile is a related but different artifact: a scoped subset or combination of standards. A profile can constrain a reference design without being the design itself.
Machine-checkable requirements can be implemented as policy as code, with tests for input quality, enforcement coverage, bypass, policy distribution, and failure handling. Continuous compliance needs repeated assessment of relevant changes; a build-time check alone is insufficient. Compare implementation and maintenance cost with manual review, and retain any required approval or judgment. Decision latency explains how to measure the resulting waits.
Where the operating arrangement fails
- Review is not performed. A date on a document does not assess changed requirements or support. Assign the review and record its resulting decision.
- Unmet needs have no clear route. Teams may hide workarounds or stop useful work. Provide an authorized response without promising that every request can be approved. For temporary accepted exposure, vulnerability exception illustrates scope, authority, reassessment, and expiry.
- Support is assumed. A preferred product needs an explicit operating and support arrangement, which may place duties with the user team. A golden path can package a supported route through platform services; a standard alone does not supply it.
- Approval as the only enforcement. If compliance is checked only by a board, the standard is as strong as the board’s attention and as fast as its calendar. The bodies involved are covered in governance body.
How scope, approval, expiring exceptions, accumulated debt, and team autonomy fit together is worked through in A Standard Nobody Could Deviate From.
References
- NIST Computer Security Resource Center Glossary, standard. The definition summarized here is attributed on the page to NIST SP 800-175A.
- GOV.UK, Open Standards principles (updated 5 April 2018), published under the Open Government Licence v3.0 — review of compulsory standards, the exemption route, and standards-based profiles.
- DORA, Capabilities: Empowering teams to choose tools — the recommended baseline of approved tooling and a defined process for deviating from it.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.