How to use this pillar
Trust Architecture Playbook: Governance pillar
The Governance pillar is designed to be broad and should be read selectively. Readers need not need to consume every section before acting, they need to know which artifacts, controls, and decisions are applicable to their role.
Pillar guidance by audience
Start with the row that matches your role, then follow the referenced artifacts.
Audience | Read first | Then use | Decision or action |
|---|---|---|---|
Executives and risk owners | Dashboard trends, exception posture, crypto-agility readiness, and funding blockers | Confirm authority, fund remediation, and accept or reject residual risk across the full digital trust operating model. | |
PKI and Trust Lifecycle Manager owners | Registries, profile catalog, CA governance, access model, metadata, service users, and audit export | Build and operate the Trust Lifecycle Manager control plane in the right order. | |
Governance, risk, and compliance (GRC) and audit stakeholders | Artifact ownership, evidence sampling, exception review, dashboard signals, and audit support | Set evidence expectations and verify that governance controls operated as designed. | |
Platform owners | CA source and connector requirements, deployment validation, runbooks, automation identities, and recovery paths | Keep platforms, namespaces, integrations, and validation loops ready for governed lifecycle execution. | |
Service owners | Lifecycle governance, namespace/domain authorization, exception intake, and remediation commitments | Keep service context, ownership, criticality, names, and risk acceptance current. |
Governance artifact matrix
The artifact matrix provides a one-page index for the governance operating model. Each artifact must have an owner, review cadence, source of record, and dashboard/signal. The artifacts below are intentionally small; they become useful when they are current and enforced.
Artifact | Purpose | Primary owner | Main use |
|---|---|---|---|
Governance charter | Decision rights, quorum, escalation, and authority. | PKI governance board | Approvals and escalation. |
Trust-domain registry | Approved trust environments and evidence model. | Policy authority | Scope and control selection. |
CA source registry | Approved CAs, allowed scope, owner, and exit plan. | Central PKI | CA onboarding and profile binding. |
Profile catalog | Approved certificate profiles and constraints. | Profile owner / central PKI | Requests, renewals, and automation. |
Domain / namespace registry | Public domains, internal namespaces, and workload identity boundaries. | Domain, DNS, platform, and service owners | SAN and delegation decisions. |
Service-user register | Non-human identities, API clients, ACME accounts, connectors, and scope. | Trust Lifecycle Manager owner / identity team | Access review and rotation. |
Exception register | Time-boxed deviations, compensating controls, owners, and expiry. | Governance board / GRC | Risk acceptance and retirement. |
Evidence pack | Approval-to-validation proof for lifecycle events. | GRC with PKI support | Audit, incidents, and assurance. |
Governance dashboard | Control health, decision signals, and trends. | Program owner | Triage and executive reporting. |
Minimum viable governance
Minimum viable governance is the smallest set of decisions and artifacts required to stop unmanaged trust growth while the full operating model matures. It is deliberately not the mature end state. It gives teams enough clarity to know who can decide, what is allowed, what must be recorded, and how exceptions are handled.
Minimum viable control | Why it matters | First artifact |
|---|---|---|
Name the PKI governance authority. | Eliminates ambiguity about who can approve trust domains, CA sources, profiles, delegation, and exceptions. | Governance board charter or named policy authority. |
Define the initial trust-domain taxonomy. | Creates a first control boundary for public TLS, private TLS, workload identity, user/device, code signing, S/MIME, and special-purpose PKI. | Trust-domain registry. |
Create the CA source registry. | Prevents new issuance from unapproved public CAs, private CAs, cloud CAs, lab CAs, or legacy issuing paths. | CA source registry with owner, scope, trust type, and disposition. |
Freeze uncontrolled profile creation. | Stops profile sprawl before the profile catalog can be rationalized. | Interim profile intake rule and approval queue. |
Approve minimum metadata standards. | Makes ownership, risk, routing, and evidence possible before the inventory is perfect. | Mandatory fields: owner, environment, criticality, exposure, platform, trust domain, and CA source. |
Define service-user and automation-identity rules. | Prevents API, ACME, connector, and CI/CD identities from becoming unbounded issuance authority. | Service-user standard with owner, scope, rotation, and disable path. |
Stand up the exception register. | Keeps deviations visible, time-boxed, and tied to remediation rather than letting them become the operating model. | Exception register with expiry date, compensating controls, and retirement plan. |
Create the governance dashboard. | Turns governance from an intent statement into a measurable operating control. | Dashboard for unowned certificates, unmanaged CA sources, profile drift, CT log anomalies, high-risk expirations, access review status, and open exceptions. |
Importante
Adoption rule
If these eight controls do not exist, do not treat the program as governed. Treat it as a transition state and keep new trust creation under explicit review until the minimum viable controls are operating.
Governance transition states
Most enterprises are not starting from clean governance. The practical goal is to move the estate through known transition states without pretending that every certificate, CA, profile, and automation identity is already compliant.
State | Typical reality | Governance objective | Exit criteria |
|---|---|---|---|
Current unmanaged state | Certificates, profiles, CA sources, owners, and install locations are incomplete or inconsistent. New trust may still be created through local practices. | Stop uncontrolled growth and identify the highest-risk unknowns. | Governance authority named; uncontrolled profile creation frozen; initial trust-domain and CA source registries created. |
Transitional governed-discovery state | Discovery and reconciliation are underway, but certificate ownership, metadata, and CA-source disposition are not yet complete across the estate. | Bring unknown assets into inventory and classify them without normalizing weak controls. | Tier 0/1 assets mapped to owners and CA sources; minimum metadata standard operating; remediation backlog active. |
Governed exception state | The standard model is defined, but some assets cannot yet meet profile, automation, metadata, or evidence requirements. | Keep deviations time-boxed, approved, evidenced, and tied to retirement plans. | Exceptions are current, reviewed on cadence, aging down, and clustered patterns are converted into standard patterns or decommission plans. |
Target governed state | Approved trust domains, CA sources, profiles, ownership, access, evidence, and lifecycle controls operate through a managed control plane. | Maintain the system, measure drift, and continuously tighten controls as discovery, issuance, and automation mature. | This is the operating state. The program stays healthy through cadence, metrics, access review, profile review, and crypto-agility exercises. |
Dica
Transition-state discipline
Do not label the program mature because a tool has been deployed. Maturity starts when transition-state assets are visible, owned, risk-ranked, and moving toward standard governance or approved retirement.