This checklist is not a compliance framework — it's a practical assessment tool for enterprise ML platform teams. Use it to identify gaps in your current governance posture, prioritize remediation, and create a shared vocabulary with your compliance and risk stakeholders about what "governance-ready" means for your model portfolio.
The 24 controls are organized across four domains. Each control is scored as: Implemented (evidence exists and is current), Partial (some evidence exists but gaps remain), or Not Implemented. A team that is Implemented on all 24 controls has the foundation for a defensible ML governance audit response. A team that is Not Implemented on more than eight controls in any single domain has a material gap.
Domain 1: Version Lineage (6 controls)
VL-1: Model version identifiers are immutable and globally unique. Every model artifact that has ever served production traffic has a unique identifier that cannot be reused. Rollback decisions reference a specific version identifier, not a relative position ("previous version").
VL-2: Training provenance is recorded per model version. For each production model version, you can identify: the training dataset version or hash, the feature pipeline version, the training code commit SHA, and the hyperparameter configuration. This is typically satisfied by MLflow or equivalent artifact tracking.
VL-3: Ancestor chain is queryable. You can answer: what is the parent version of the current production model? What was the parent's parent? This DAG should be queryable programmatically, not just visible in a UI.
VL-4: Promotion and demotion events are recorded with timestamps. Every time a model version's status changed — to candidate, to production, to rolled-back — there is an immutable record with a UTC timestamp and an actor identifier.
VL-5: Current production version is queryable as a point-in-time fact. You can answer: what model version was serving predictions for model X on date Y? This requires timestamp-bounded production state records, not just current state.
VL-6: Feature schema compatibility is verified on promotion. Before a new model version enters production, the serving infrastructure's feature schema is compared against the model's expected input schema. Incompatibilities block promotion or generate a documented exception.
Domain 2: Drift Monitoring (6 controls)
DM-1: Drift detection is configured for all production models. Every production model has at least one configured drift metric with a defined threshold. "Configured" means machine-readable policy, not a note in a Confluence doc.
DM-2: Baseline distributions are versioned alongside model artifacts. The baseline distribution used for drift calculation is tied to the specific model version, not to a global historical window that shifts without being tracked. When a model is retrained, the baseline is updated explicitly and the update is recorded.
DM-3: Drift alerts are acknowledged within a defined SLA. You have a documented SLA for responding to drift alerts, and you have records showing that alerts were acknowledged within that SLA during the review period. Unacknowledged alerts older than the SLA are a control failure.
DM-4: Output distribution is monitored in addition to input features. Prediction score distribution (the distribution of the model's output values) is monitored separately from input feature distributions. Output distribution shift can signal concept drift when input distributions appear stable.
DM-5: Drift metrics are chosen appropriately for the model type. You have a documented rationale for the drift metrics used for each model — PSI for tabular credit-type features, Wasserstein for score distributions, KL divergence for categorical covariate shift, etc. "We use PSI for everything" is not an adequate answer for models with continuous output distributions.
DM-6: Threshold calibration is documented per model. Drift thresholds are calibrated to the model's historical drift velocity, not borrowed from generic guidelines. The calibration methodology is documented and available for audit review.
Domain 3: Retrain Authorization (6 controls)
RA-1: Every retrain event is associated with an authorization record. No production model retrain occurred without a corresponding governance event that records: who authorized it, under what policy, at what timestamp. Automated retrains are authorized by policy (the policy is the authorization); policy-authorized retrains are recorded as automation events, not as unattributed executions.
RA-2: Retrain policies are version-controlled and attached to governance events. The policy version that governed each retrain event is immutably attached to the event record. Policy changes are versioned, not edited in place.
RA-3: Quality gates are defined and enforced per model. Each model has explicit quality gate criteria that a new version must pass before promotion. Quality gate evaluations are logged with the evaluation dataset version and the results of each gate criterion.
RA-4: Approval chains match model risk tier. High-risk models have documented multi-role approval requirements. The mapping of models to risk tiers is explicit and reviewed at least annually.
RA-5: Approval SLAs are defined with timeout escalation paths. Every approval requirement has a defined SLA and a documented escalation path for timeout. Approval SLA exceedances are logged and reviewed.
RA-6: Emergency retrain procedure is documented and practiced. You have a documented procedure for emergency retrains (production incidents requiring immediate model updates) that specifies: who can authorize under emergency conditions, what governance events are required even during emergencies, and what post-incident review is required.
Domain 4: Audit Readiness (6 controls)
AR-1: Governance events are immutable after creation. Governance records cannot be edited or deleted by any user in the normal operation of the system. Immutability is enforced at the storage layer, not by policy alone.
AR-2: Audit log export is available in structured format. You can export all governance events for any model or date range in a structured format (CSV or JSON) in under one hour without engineering involvement.
AR-3: RBAC assignments are auditable. You have a record of who held each governance role for each model during the review period. Historical role assignments are queryable; current role assignments alone are not sufficient for a Type 2 review.
AR-4: Policy change history is accessible. For each model, you can retrieve the complete history of policy versions with the timestamp each version became effective. Auditors should be able to identify which policy version governed any specific governance event.
AR-5: Governance records are retained for the required period. Your retention policy for governance records matches or exceeds the relevant regulatory and contractual requirements. Retention is enforced at the storage layer, not by manual process.
AR-6: Cross-model governance summary is producible on demand. You can produce, within a business day, a summary of governance posture for your full model portfolio: models currently in production, their last retrain dates, current drift status, and open approval requests. This executive summary view is not just a reporting convenience — it's evidence that your governance system operates at the portfolio level, not just the per-model level.