How does a formal technology standards catalog with allow/deny lists differ from a tech radar in how it governs what engineers can use, and how do the two mechanisms typically work together?

## Two artifacts, two jobs These two artifacts sit at different points on the spectrum between **exploration** and **enforcement**, and a mature enterprise architecture practice deliberately keeps them separate rather than merging them into one document, because collapsing them either kills experimentation (if everything requires allow-list approval) or lets ungoverned risk creep into production (if nothing is ever hard-blocked). ## Inside the catalog **Mechanism — the standards catalog:** this is a specific, usually versioned inventory. | Entry | Ruling | |---|---| | `Java 21 LTS` | allowed | | A particular `Log4j` version below the patched release | denied due to a known critical CVE | | `PostgreSQL 14+` | allowed | | A particular unsupported ORM | denied, end-of-life | Because it's meant to be enforced, not just consulted, it's typically wired into automated gates: - a software composition analysis (`SCA`) tool or dependency-scanner in CI fails the build if a denied library or version appears in a manifest; - a cloud landing zone's service control policies block provisioning of a non-approved managed service; - procurement won't sign a contract for a deny-listed SaaS vendor. The catalog is deliberately **narrow in scope** — it only needs to cover things specific enough to check mechanically (a package name and version range, a cloud service SKU, a vendor name) — and it changes primarily in response to concrete triggers: - a new CVE; - a license change; - a vendor going out of business or announcing end-of-life; - or a security/legal review outcome. ## Inside the radar **Mechanism — the radar:** by contrast, the radar is deliberately **broad and low-friction**. - It covers whole categories and techniques, not just specific approved package versions. - Most of it isn't hard-enforced. - It exists specifically to let evidence accumulate about things the catalog hasn't ruled on yet. A technology sitting in Assess or Trial on the radar is neither allowed nor denied in the catalog's binary sense — a team can typically still use it for a contained pilot without triggering a compliance gate, provided normal security review still applies. The radar's currency is narrative and trend ('gaining traction across three teams,' 'losing ground to a newer alternative'), not pass/fail. ## Why both exist - **An organization that only had a strict allow/deny catalog** would strangle its own ability to evaluate new technology, because everything unlisted would default to 'not allowed' or would require a heavyweight approval request before anyone could even prototype with it — that pushes experimentation underground into shadow IT, which is worse for governance, not better. - **An organization that only had a radar, with no enforceable catalog,** would have no mechanical way to actually stop a known-vulnerable library or a licensing-incompatible dependency from shipping — advisory guidance alone doesn't stop a deadline-pressured team from using whatever compiles. The two-layer design gets the benefit of both: cheap, low-stakes exploration at the radar layer, and hard enforcement only where the cost of a mistake (a security breach, a license violation, a vendor lock-in nobody chose) is high enough to justify friction. ## Trade-offs Keeping them separate costs coordination — someone has to own the handoff from 'this graduated to Adopt on the radar' to 'therefore add it to the catalog's allow list,' and if that handoff process is weak, teams get whiplash (the radar says it's fine, but the CI gate still fails). Merging them into a single strict list is simpler to maintain but reintroduces the innovation-vs-shadow-IT problem above. There's also a genuine trade-off in **strictness** itself: an overly aggressive deny list, applied without a fast exception path, will get engineers to reach for workarounds (vendoring a denied library under a different name, using personal cloud accounts) — the deny list needs a documented, reasonably fast waiver process or it undermines its own authority. ## Failure modes in production - **Catalog drift** — the classic failure mode. The allow list still lists a library version that was superseded long ago, so the CI gate blocks legitimate upgrades and teams either ignore the gate (adding it to a suppressions file that never gets revisited) or file exception tickets that queue for weeks. - **A catalog with no deny list at all, only an allow list** — another failure. It silently blocks anything new (including legitimate improvements) by omission rather than by deliberate decision. - **A radar that references items the catalog contradicts** — a third. Something is 'Adopt' on the radar's public-facing page but was never actually added to the enforced allow list, so builds fail unexpectedly for teams that trusted the radar. ## The two layers in practice A concrete instance: a bank's Cloud Center of Excellence might run a tech radar to track evaluation of message brokers across teams, while its security team maintains a separate, CI-enforced software-bill-of-materials allow/deny policy pulled from a vetted internal package repository, plus an OSS license-scanning gate — so that a broker can be actively in Trial on the radar (real pilot, real evidence-gathering) while remaining ungated in the strict compliance sense until it clears its own security review and is added to the enforced repository.