Certificate Governance and the Steering Function

Certificate governance is the part of the operating model that decides what is allowed before the operations team decides how to deliver it. Without explicit governance, every team across the enterprise makes local cryptographic decisions — algorithm choice, validity period, CA selection, key protection — that don't compose at the organisation level. The CISO discovers this during the first audit.

Part of: Enterprise PKI Operating Model — the pillar page for the operations library.

Governance is not policy documents. Policy documents are the artefact. Governance is the function that produces them, maintains them, exercises them when exceptions arise, and updates them as the threat landscape and the regulatory environment shift.

What certificate governance covers

Five questions define the governance scope for any PKI operating model. The right answer depends on the organisation; the wrong answer is no answer at all.

Who owns PKI at the executive level? This is rarely a clean answer. PKI sits at the intersection of security (the CISO), infrastructure (the CTO or VP Engineering), and compliance (the CRO or Head of Audit). In most organisations, the de facto owner is whichever of these three first encountered a major certificate incident. The de jure owner is often unclear. Until the executive owner is named — and the others have agreed — every governance decision is a negotiation rather than a directive.

What is the policy framework? The set of rules that govern issuance, key management, validity, revocation, and CA usage. This typically lives in a Certificate Policy (CP), a Certification Practice Statement (CPS), and a set of operational standards that translate policy into engineering practice. Policy without practice translation is shelf documentation.

How are exceptions approved? Every policy generates exceptions: a service that needs a longer validity period, a team that wants a different CA, a legacy system that cannot use the standard automation. The governance function defines who approves exceptions, how they are documented, how they are time-bounded, and how they are reviewed for closure. Without exception governance, the policy quietly becomes irrelevant.

Who sets cryptographic algorithm policy? Algorithm choice (RSA vs ECDSA vs Ed25519, key sizes, hash algorithms, supported TLS versions) is a security decision with operational consequences. The governance function decides; the operations function implements. Conflating these — letting the team that runs the CLM also decide what algorithms to support — produces predictable drift.

How are post-quantum and crypto-agility decisions made? The question is no longer hypothetical. NIST has finalised post-quantum standards. CA/Browser Forum is shortening certificate validity. Governance has to decide when the organisation begins post-quantum migration, what the parallel-PKI strategy looks like, and how crypto-agility is built into the operating model rather than retrofitted. See the PQC migration and crypto agility guide.

The steering function

A steering group is the executable form of governance. It makes decisions that the operations team carries out. The shape of the steering group depends on organisation size and regulatory exposure, but the function is always the same.

Composition. The executive owner (whoever was named in the first question above), the operations lead, a representative from compliance/audit, a representative from each major engineering function that consumes certificates (typically infrastructure, applications, identity, networking), and — where the organisation is regulated — a representative from the regulatory function. Smaller organisations compress these roles into fewer people; larger organisations split them across more. The minimum viable steering group is three people.

Cadence. Monthly is the right baseline cadence. Quarterly creates drift; weekly creates fatigue and devolves into operations standups. Monthly with a clear agenda (policy review, exception register, incident review, programme status, upcoming change forecast) keeps governance current without consuming time disproportionate to the function.

Scope. The steering group decides; it does not execute. The mature pattern is: operations brings problems and recommendations to steering, steering decides between options, operations executes the decision, the next steering meeting reviews outcomes. The immature pattern — and the most common one — is steering as a status update where decisions are deferred and operations continues to make them by default.

Documentation. Decisions are minuted, including the considered alternatives and the reasoning. This produces the governance audit trail that compliance functions need and creates institutional memory that survives turnover in either the steering group or the operations team.

Where governance breaks

Three failure patterns recur across organisations.

The implicit-owner problem. No-one was ever explicitly named as the executive owner of PKI. The de facto owner is whichever VP gets pulled into the next certificate-driven incident. This is fine — until that VP changes role, and the next incident reveals that no-one inherited ownership. The fix is explicit: name the owner in writing, document the role, transition it deliberately when the named person changes. This is a thirty-minute exercise that most organisations defer indefinitely.

The policy-practice gap. A Certificate Policy exists. It says all certificates must use 2048-bit RSA minimum, validity must not exceed 397 days, and private keys must be stored in HSMs for production CAs. None of these requirements have been translated into engineering controls. The policy is what compliance reviews; the practice is what runs in production. The fix is to translate each policy clause into either an automated check (preferred) or a documented manual control with a named owner.

The exception graveyard. Exceptions accumulate. Each one had a good reason at the time. None of them are being reviewed. After three years, the exception register has more entries than the policy has clauses, and no-one can remember which exceptions are still required. The fix is exception governance with mandatory time-bounding: every exception has an expiry date, a named owner, and a review trigger. Exceptions without expiry are not exceptions; they are policy.

Parameterised governance — what determines the right shape

The governance structure that fits a 200-engineer fintech is not the structure that fits a 50,000-employee bank, and neither fits a 1,000-employee broadcast company. Three parameters determine the right shape:

Estate size and complexity. The number of certificates under management, the number of distinct CAs, the number of operating environments. Below roughly 5,000 certificates, governance can be informal — a named owner and a documented policy. Between 5,000 and 50,000, formal steering becomes necessary. Above 50,000, the steering function typically splits into a strategic group (quarterly, executive) and an operational group (monthly, technical leadership) with clear handoffs between them.

Regulatory exposure. Telecommunications (TSA/TSR in the UK), financial services (PCI, PRA, FCA, DORA in the EU), healthcare (HIPAA, NHS DSP Toolkit), critical national infrastructure (NIS2 in the EU), and government (FedRAMP, public-sector frameworks) each impose specific governance requirements. The steering group composition has to reflect the regulatory framework — a regulated estate without a compliance representative on the steering group will fail audit. See the regulated PKI implementation guide.

Decision latency tolerance. How quickly the organisation needs to make cryptographic decisions. A high-velocity engineering culture cannot wait six weeks for a steering decision on a new algorithm. The mature pattern is a tiered decision framework: small decisions (operational, low-risk) made by the operations lead; medium decisions made by the steering group; large decisions (cryptographic policy, CA strategy, post-quantum) escalated to executive. Defining the tiers is part of the governance design.

Maturity progression for governance

The five-level PKI operational maturity model introduced in the pillar maps onto the governance domain as follows. Each level reflects how governance functions in practice rather than what is documented.

Level 1 — Ad-hoc. No named executive owner. No documented policy. Decisions are made by whichever team encounters the problem first. Exceptions are not tracked because there is no policy to deviate from.

Level 2 — Tooled. A policy document exists but is rarely consulted. An owner is named informally — usually the person who wrote the policy. Steering happens reactively after incidents. Most organisations sit here and assume they are higher.

Level 3 — Operationalised. A steering group meets on a defined cadence. Policy is reviewed annually. Exceptions are documented but not always time-bounded. Decisions are minuted. The governance function is recognisable as a function rather than a series of ad-hoc reactions.

Level 4 — Integrated. Governance is integrated with adjacent functions — architecture review, change advisory board, security council. Exceptions are time-bounded and reviewed. Policy is updated in response to environmental change rather than only on annual cycle. Cryptographic decisions reach the right authority at the right velocity.

Level 5 — Intelligent. Governance is forward-looking. Post-quantum, crypto-agility, and regulatory change are tracked and incorporated. The steering group is a strategic function, not an operational one. Lower-tier decisions are delegated with clear authority. The governance function shapes the operating model rather than being a downstream review of it.

Most organisations sit between level 2 and level 3 on governance. The progression to level 4 takes between six and eighteen months once the steering function is properly stood up — assuming the executive owner has been explicitly named and the policy-practice gap is being actively closed.

Further reading within this cluster

• Enterprise PKI operating model — the pillar page
• Certificate discovery in practice
• Certificate issuance workflows
• Change management for PKI operations
• PKI support model and RACI