Section 04 · Secure SDLC
NIST AI RMF, operationalized.
Secure AI development must be risk-proportionate, architecture-aware, adversarially informed, and operationally monitored. This framework embeds AI controls across the lifecycle while aligning to the four NIST AI RMF functions: Govern · Map · Measure · Manage. The framework scales these across three tracks driven by the risk tier.
Core stance
We do not replicate NIST AI RMF. We operationalize it inside enterprise development workflows, so governance becomes part of CI/CD instead of a parallel artifact.
Three tracks
Aligned to risk tier. Each track defines required controls under Govern, Map, Measure, and Manage. Higher tiers add controls; they don’t replace lower-tier baselines.
Baseline Track
Tier 1–2Low-to-moderate impact systems. Lightweight controls, recommended adversarial testing.
Govern
- Risk tier documented
- Ownership assigned
- Data classification confirmed
Map
- Architecture diagram created
- Data sources documented
- Third-party dependencies identified
Measure
- Basic performance metrics defined
- Logging enabled
- Monitoring thresholds defined
Manage
- Incident reporting path documented
- Model versioning enforced
Enhanced Track
Tier 3Customer-facing, sensitive, or regulatory-exposed systems. Adversarial integration begins here.
Govern
- Governance validation required
- Vendor AI review formalized
- Bias evaluation summary documented
Map
- Formal threat model completed
- ATT&CK / ATLAS mapping for relevant adversarial techniques
- Automation flow documented
Measure
- Pre-deployment evaluation suite (capability, safety, regression baselines, jailbreak)
- Drift detection thresholds defined
- Abuse case simulations performed
- Logging validated for forensic use
Manage
- Escalation triggers defined
- Model rollback procedure tested
- Red team testing performed where applicable
High-Assurance Track
Tier 4Regulated decisions, financial or employment impact, fully automated systems, or high-reputation risk.
Govern
- Executive visibility
- Formal risk acceptance documentation
- AI risk committee review (where maturity allows)
Map
- Full architecture threat modeling
- ATLAS adversarial technique mapping
- Third-party supply chain risk mapping
- Documented training data provenance and lineage (sources, licensing, consent basis, contamination checks)
Measure
- Structured adversarial testing
- Bias and fairness analysis
- Explainability documentation
- Continuous drift monitoring dashboard
- Pre-deployment evaluation suite required, with regression gating on release
Manage
- Real-time anomaly alerting
- Incident response integration
- Regulatory reporting playbook
- Periodic model review cadence
Control inheritance
Don’t make product teams re-implement platform controls.
Controls may be inherited from platform-level logging enforcement, the centralized model registry, infrastructure security baselines, and vendor due diligence templates. Product teams only implement controls not already inherited. This is the difference between governance that scales and governance that creates duplicate work.
Tier 3+ requirement
Vendor AI due diligence checklist
For any third-party model, fine-tuning service, or AI-powered vendor capability. Failure on any item is not automatic disqualification; it is a documented risk acceptance.
Executive reporting (Tier 3–4)
- Active AI systems by tier
- Drift incidents
- AI-related security incidents
- Vendor AI dependencies
- Open risk acceptances
- Pre-deployment eval pass rates
Risk visibility, without micromanaging product teams.