Integrated Assurance
The Integrated Assurance Maturity Model (IAMM)
The IAMM provides a way to understand how effectively an organization has integrated assurance across the business, where fragmentation still exists and what should change next.
Maturity is not a score
Organizations rarely move from fragmented assurance to integrated assurance in one step, and no organization needs to reach the final level everywhere to benefit from the model.
The IAMM is intended to show where assurance is fragmented, where coordination is developing and where assurance has become part of how the organization actually operates.
More importantly, it helps leadership decide where greater maturity would create meaningful business value. The objective is not to achieve Level 5 everywhere. It is to understand the current condition honestly and make deliberate decisions about what needs to improve.
The question is not how mature the organization can become. It is how mature it needs to be.
The maturity levels
From fragmented activity to institutionalized capability
01Fragmented
Assurance activities largely operate independently, with limited shared governance, inconsistent integration and isolated measures.
02Defined
Policies, frameworks and basic practices exist, but integration and cross-functional application remain inconsistent.
03Aligned
Cross-functional practices begin to emerge. Ownership becomes clearer, shared information improves and assurance activities become more coordinated.
04Embedded
Assurance becomes integrated into governance, engineering, operational processes, measurement and decision-making.
05Institutionalized
Assurance functions as an enterprise capability and is embedded in strategic planning, governance, culture and continuous decision-making.
The six domains
An organization does not have one maturity level
The IAMM evaluates maturity across six organizational domains. This matters because organizations rarely mature evenly. Governance may be highly developed while operational integration remains fragmented. Architecture may be mature while metrics still provide little business context.
Looking at the domains independently exposes those differences and helps leadership see where fragmentation creates dependencies, gaps or unnecessary friction.
Governance
How assurance is governed, coordinated and connected to enterprise decisions.
Architecture & Engineering
How assurance is incorporated into architecture, design and engineering practices.
IT & Engineering Operations
How assurance becomes part of operational processes, change, recovery and day-to-day execution.
Risk, Compliance & Audit
How controls, risk information, compliance activities and audit are coordinated rather than managed as separate views of the organization.
Metrics & Reporting
Whether measurement provides leadership with meaningful information about risk, performance, remediation and business consequence.
Culture & Collaboration
Whether responsibility for assurance is shared across the organization and reinforced through leadership behavior and working practices.
The model
Six domains across five levels
Governance
Level 1 · Fragmented
Security and IT operate in silos with no shared governance mechanisms.
Level 2 · Defined
Policies exist but lack cross-functional enforcement or integration.
Level 3 · Aligned
Cross-functional risk forums and workflows are emerging.
Level 4 · Embedded
An Integrated Assurance Council oversees risk, investment, and policy decisions.
Level 5 · Institutionalized
Assurance is integral to strategic planning and enterprise governance.
Architecture & Engineering
Level 1 · Fragmented
Security is applied after-the-fact with little design integration.
Level 2 · Defined
Reference architectures exist but are inconsistently applied.
Level 3 · Aligned
Secure-by-design principles adopted in review cycles.
Level 4 · Embedded
Reusable secure patterns and policy-as-code are integrated into engineering pipelines.
Level 5 · Institutionalized
Assurance is a foundational design constraint; artifacts are governed and auto-validated.
IT & Engineering Operations
Level 1 · Fragmented
Availability is prioritized over security; controls are ad hoc or absent.
Level 2 · Defined
Basic security checks incorporated into change control processes.
Level 3 · Aligned
Shared telemetry and partial control ownership across teams.
Level 4 · Embedded
Policies and recovery standards are automatically enforced across systems.
Level 5 · Institutionalized
Operations are accountable for assurance KPIs; assurance is embedded in every lifecycle phase.
Risk, Compliance & Audit
Level 1 · Fragmented
Risk registers are static; audits are limited and event-driven.
Level 2 · Defined
Compliance frameworks are adopted inconsistently, contributing to audit fatigue.
Level 3 · Aligned
Control harmonization is in progress; ownership is being clarified.
Level 4 · Embedded
Control testing is automated; compliance is federated across domains.
Level 5 · Institutionalized
Assurance is adaptive, continuous, and audit-ready by default.
Metrics & Reporting
Level 1 · Fragmented
Isolated, technical metrics lacking context or strategic use.
Level 2 · Defined
Output-driven dashboards in place.
Level 3 · Aligned
Risk and remediation timelines are tracked collaboratively.
Level 4 · Embedded
Metrics drive prioritization, governance, and resource allocation.
Level 5 · Institutionalized
Metrics demonstrate convergence, impact, and cultural adoption of assurance.
Culture & Collaboration
Level 1 · Fragmented
Security is seen as obstructive; no shared responsibility.
Level 2 · Defined
Awareness is basic and engagement reactive.
Level 3 · Aligned
Assurance champions emerge; inter-team collaboration begins.
Level 4 · Embedded
Security roles are embedded; cross-functional collaboration formalized.
Level 5 · Institutionalized
Security and assurance are core cultural values reinforced by leadership behavior.
From assessment to action
Knowing where you are is different from knowing what to do next
The IAMM establishes the current condition. The Integrated Assurance implementation methodology provides a practical way to move from that condition toward greater coordination where greater maturity is warranted.
The two should not be treated as identical five-step scales. Maturity is assessed across organizational domains. Implementation is shaped around the organization’s actual gaps, priorities and operating environment.
IAMM tells you where assurance stands. The implementation methodology helps determine what happens next.
The practical path
Five stages for building Integrated Assurance
Stage 1
Define Strategic Intent and Organizational Alignment
Establish leadership consensus, define shared outcomes and prepare the enterprise for a unified assurance model.
Stage 2
Baseline Capabilities and Identify Friction Points
Assess current assurance maturity, surface capability fragmentation and identify control breakdowns and operational friction.
Stage 3
Execute Targeted Pilots and Codify Patterns
Demonstrate value through focused pilots while developing reusable patterns, traceability and practical operating approaches.
Stage 4
Operationalize Assurance at Scale
Expand assurance across the enterprise through repeatable practices, automation, federation and governance loops.
Stage 5
Institutionalize Assurance as an Enterprise Capability
Embed assurance into leadership, strategic decision-making, funding, governance and continuous improvement.
Explore the implementation methodology
Stage 1
Define Strategic Intent and Organizational Alignment
Key actions
- Appoint an executive sponsor and Integrated Assurance Lead
- Form a cross-functional Assurance Council
- Ratify a shared mission, principles, and outcomes
- Identify regulatory or transformation drivers
- Socialize the vision across domains
Success indicators
- Executive sponsorship formalized
- Shared vocabulary established
- Strategic alignment across the enterprise
Stage 2
Baseline Capabilities and Identify Friction Points
Key actions
- Inventory existing frameworks, controls, and governance
- Map controls to business processes
- Document known issues and audit failures
- Capture pain points from operations, delivery, and risk
Success indicators
- Gaps and friction points clearly documented
- Ownership ambiguity and control duplication identified
- Quick wins and systemic blockers prioritized
Stage 3
Execute Targeted Pilots and Codify Patterns
Key actions
- Launch high-impact pilots (DevSecOps, vendor risk, identity)
- Establish traceability between controls and execution
- Develop reusable playbooks and design patterns
- Build dashboards to visualize assurance
Success indicators
- Operational teams validate pilot outcomes
- Patterns and templates reused across teams
- Assurance becomes traceable and measurable
Stage 4
Operationalize Assurance at Scale
Key actions
- Deploy federated assurance operating model
- Offer self-service templates and secure defaults
- Integrate assurance into change and planning cycles
- Embed security and compliance roles in delivery teams
Success indicators
- Risk ownership is internalized at team level
- Assurance behaviors embedded in workflows
- Metrics support continuous investment decisions
Stage 5
Institutionalize Assurance as an Enterprise Capability
Key actions
- Evolve the Assurance Council into a governance body with funding authority
- Integrate assurance metrics into enterprise dashboards
- Adopt continuous improvement loops
- Leverage posture for external assurance and board reporting
Success indicators
- Assurance posture influences enterprise decisions
- Leadership owns and understands risk
- Organization demonstrates resilience and defensibility
Using the model
Start with how the organization actually operates
An IAMM assessment should not begin with a questionnaire designed to produce a maturity score.
It begins by examining how assurance actually works across the six domains. Existing frameworks, reporting, governance, operating practices and evidence help establish the current condition. Interviews help explain why those conditions exist and where fragmentation affects the business.
The result is not simply six maturity ratings. It is a view of where assurance is working, where coordination breaks down and which improvements would create the most useful change.
The useful output is the gap between current maturity and required maturity
An organization may determine that Level 3 is entirely appropriate in one area while Level 4 or Level 5 is necessary somewhere else. That is not a weakness in the model. It is the point of using it.
The assessment should identify where current maturity is sufficient, where additional coordination would reduce risk or friction and where the organization may be investing in maturity that does not materially improve the business.
IAMM Self-Assessment
How integrated is assurance across your organization?
The IAMM Self-Assessment gives you a quick view across the six domains of Integrated Assurance and helps identify where assurance is coordinated, where it remains fragmented and where a closer look may be useful.
18 questions · 6 domains · About 5 minutes
This provides an indicative maturity profile and is not a formal IAMM assessment.
Maturity without business context becomes another compliance exercise.
Origins
Built from enterprise architecture and assurance work
The IAMM grew from Patrick M. Hayes’ work in enterprise security architecture, assurance, governance and operations. Patrick became a Zachman Enterprise Architect in 2000, which shaped his approach to viewing organizations as interconnected systems rather than collections of independent functions.
Over more than two decades of architecture, assessment, security operations, governance and executive work, the same problem repeatedly appeared: capable functions could each hold valid views of risk while leadership was still left to reconcile those views at the moment a decision had to be made.
Integrated Assurance developed from that problem. The IAMM provides a way to assess how far an organization has progressed from fragmented functional assurance toward a more coordinated enterprise capability.
An assessment conversation is usually the faster route to a useful answer.
The objective is not to sell an organization a path to Level 5. It is to understand where greater coordination would actually matter.