Technology Standards and Exceptions

Consider a fictional organization whose integration standard requires the approved broker for asynchronous messaging. After an outage involving several messaging systems, it consolidated operations and on-call knowledge. Its next audit reported full compliance within the scope examined.

Three years later, a platform review discovers four other systems moving messages: a streaming platform needed for ordered replay at a volume outside the broker’s design, a component bundled with a vendor product, and two pilots. None has an architecture record. In this example, teams worked around an unmet need because there was no usable route to request a departure. The standard also names a broker version two major releases behind, with no owner assigned to review its continued suitability.

This is a failure of scope, visibility, and continuing ownership. An exception process could have exposed the unmet need, but it would not necessarily have approved it. Some requirements permit alternatives; others require redesign or stopping the proposed work. Technology standards need an explicit scope, status, review process, and authorized response when a team cannot comply.

What consistency is worth, and where

NIST’s general definition of a standard covers requirements, specifications, guidance, and characteristics used consistently for fitness of purpose. For an internal technology rule, that means stating which problem and conditions it addresses. A choice that does not serve the intended use needs review, while requirements imposed for wider organizational protection still need to be met or changed by the appropriate authority.

DORA’s guidance on team tool choice asks organizations to balance practitioners’ needs with acquisition, support, and cross-team communication costs. A shared choice can save integration effort; a poorly fitting choice can create workarounds. Compare the complete costs and benefits of the available options. Technology standard explains how to record the scope and operating rules of the choice.

Choosing what to standardize

Start with who depends on the choice and which obligations it affects. The following categories illustrate possible allocations; the examples do not exempt a tool from wider controls.

Tier	Typical subjects	Why
Common requirements and coordinated choices	Cross-team interfaces, identity and access, observability formats, data classification, shared operations	Agree interoperable contracts and required controls. Multiple implementations may satisfy them; a single platform is justified where its benefits outweigh the constraints
Supported baseline with alternatives	Languages, frameworks, databases, testing tools	A default can reduce setup and support work. Assess alternative fit, compatibility, support, and applicable approval requirements
Delegated local choice	Internal libraries, code structure, editors, local tooling	Keep decisions with the team within its authority. Dependencies, extensions, licenses, credential access, and shared maintenance can still require organization-wide controls

DORA recommends a baseline broad enough to serve most organizational needs and periodic review with practitioners. Repeated exceptions can reveal missing support, transition costs, or an unsuitable standard. Investigate those causes before adding another option or treating the exceptions as noncompliance.

A reference architecture shows how components, relationships, and design choices can address a recurring problem under stated conditions. A runnable example can demonstrate one implementation. A golden path adds a supported route through platform capabilities, with an operating commitment; it is not simply another name for the sample. Standard development paths and the platform contract develops that agreement.

Choosing how to check and enforce a standard

Rules for approved images, encryption settings, regions, or labels are candidates for policy as code. Specify when checks run, which paths enforce their decisions, how policy versions reach those points, and what happens on failure. A deployment-time check does not establish that a setting remains compliant after later changes. Include re-evaluation, bypass protection, and maintenance cost. A pipeline template can carry checks into delivery, but reuse alone does not prevent a consumer from bypassing them.

Assign each approval within explicit scope and authority, retaining independent approval where required even if some checks are automatic. Decision rights describes the allocation, governance body the mandate of a reviewing group, and decision latency the cost and measurement of waiting. Forty Approvals and Two Rejections compares automation and review using protection, cost, and residual judgment rather than rule expressibility alone.

Temporary exceptions and approved alternatives

DORA recommends a documented route for departures from a tooling baseline, including why a new tool was chosen. GOV.UK’s 2018 Open Standards principles provide a public-sector example: a government body requests an exemption with an economic appraisal and decision evidence, and the Open Standards Board considers it individually. That policy illustrates an authorization process; it is not a general entitlement to depart from any internal or external requirement.

Record the affected scope, reason, authorized decision-maker, support and control arrangements, and review triggers. Vulnerability exception provides a useful model for temporary accepted exposure, but not every supported alternative needs a promised removal date. An enduring alternative needs ownership and periodic review. A temporary exception needs an exit condition or expiry and a decision before continued use would become unauthorized. Internal approval cannot waive a binding external obligation.

• Approve an enduring alternative. Evidence may justify changing the baseline or approving a narrower alternative with a maintained support commitment. As DORA notes, documented departures can inform that decision; approval is not automatic.
• Authorize bounded continued use. Reassess current exposure and obtain approval before an exception expires. Record the permitted scope, controls, owner, and new expiry or exit condition. A contained status can prohibit expansion, but its label alone does not authorize continued operation.
• Migrate, retire, or stop. Assign a feasible transition and verify completion. A migration plan is not the completed migration, and operation during the transition needs valid authorization. Define how use will stop or be restricted if required approval is unavailable; do not silently extend an expired exception.

Read exception records alongside support requests, discovered deployments, and control results. Repeated departures for the same reason are a signal to investigate, not proof that the standard is wrong. A temporary acquisition constraint may justify a narrow exception without a new default; a widespread unmet need may justify a revised standard. Keeping the standard, improving support, or rejecting a departure can also be a considered outcome.

Standards as a way to control debt

DORA warns that unconstrained technology choices can add maintenance burden and fragility. Some of that burden may be technical debt: extra work caused by a design or implementation limitation that an improvement could reduce. Normal operating cost for a needed capability is not automatically debt interest. Compare feasible alternatives and identify the particular duplication, coupling, or workaround that creates the additional burden.

Technology status can make intended changes visible, including restrictions on new adoption and plans for deprecation. Support lifecycle explains vendor coverage and transition dates. GOV.UK recommends estimating exit and migration costs at project start; include those costs in the comparison even when no technical debt is present. A legacy system can become difficult or unacceptable to maintain for several reasons, including lost support or changed risk requirements, not only accumulated debt.

Standards also need maintenance. GOV.UK’s policy reevaluates new versions of compulsory standards against its selection criteria. An internal owner should likewise review suitability, coverage, security, and migration effort. Being two releases behind is a reason to examine those facts, not proof that upgrading to the newest release is the correct decision.

The bargain behind team autonomy

DORA describes organizations where a preferred stack receives default support and teams choosing an alternative take responsibility for supporting it. This is one operating pattern for informed choice. It still needs a clear authorization boundary and an agreement with teams affected by integration, security, cost, or incident response.

Before approving an alternative, establish whether the team can sustain it, what shared services and controls it depends on, and who will take over if ownership changes. Make both direct and cross-team costs visible. A weak default can motivate departures, but lack of adoption can also reflect migration costs or unfamiliarity. Record the reason rather than assuming it.

DORA cautions against both denying practitioners meaningful choice and allowing unconstrained variety. In the fictional example, a usable proposal route would allow the streaming requirement to be evaluated against the broker’s limits and the organization’s obligations. It could result in a new option, a narrower design, or rejection.

Judging a standards program

Use records and observed deployments to assess coverage, cost, and outcomes. Define the population and observation window for each measure so changes in inventory or detection are not mistaken for improvements in compliance.

• Share of standards with an owner and a review date that has not passed.
• Coverage of automated checks. Record which requirements, paths, and running resources are checked, which policy version applies, and what remains unobserved or requires human judgment.
• Open exceptions by age, and the number past expiry still in force.
• Exception outcomes. Distinguish renewed authorization, enduring approval, completed migration, and stopped use from proposals or plans. Adoption into the baseline is one possible result, not a required measure of learning.
• Technologies per capability. This describes variety. Read it with required functionality, actual support effort, change difficulty, risk, and transition cost; fewer technologies can still create more work.
• Time from retiring status to last use, which shows whether retirement is real.
• Use and outcomes of references or supported paths. Separate initial adoption from maintained deployments, and compare setup effort, change cost, reliability, and user experience within the intended scope.
• Discovered departures and missing records. Reconcile inventory with standards and approvals. Distinguish unauthorized adoption from permitted local choices or missing central records, and report detection coverage.

A compliance percentage needs a defined denominator, test method, observation time, and treatment of unknown resources. It may measure declarations or directly observed checks, depending on its construction. Zero recorded exceptions can reflect genuine compliance or incomplete visibility; the count alone does not distinguish them. Preserve significant choices in an architecture decision record and connect standards to the wider decisions described in enterprise architecture.

What a working program can say

A working standards program can show each rule’s purpose, scope, owner, status, and review conditions. For a departure, it can show valid authority, support commitments, and either an enduring approval or an enforceable temporary limit. For the estate, it can explain which variety is useful, where avoidable burden exists, and whether changes improved outcomes.

In the fictional broker case, an owner and review process could have surfaced the replay requirement and the aging version earlier. The organization would still need evidence and resources to choose whether to add support, retain a covered older version, migrate, or stop a pilot. Recording and reviewing those decisions makes the standard operable; it does not predetermine their outcome or timing.

References

• NIST Computer Security Resource Center Glossary, standard. The definition summarized here is attributed on the page to NIST SP 800-175A.
• DORA, Capabilities: Empowering teams to choose tools — the balance between freedom and support cost, the baseline and deviation process, the supported-default pattern, and the pitfalls at both extremes.
• 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 its evidence requirement, and estimating exit costs. Cited as an example of the structure, not as an obligation outside public procurement.