Introduction: No Single Model Fits All
One of the most consequential decisions a regulated organisation makes when establishing a DevSecOps program is how to structure security responsibilities across the organisation. This decision — the choice of operating model — determines who owns security tooling, who enforces policies, how consistently controls are applied, and how effectively the organisation can demonstrate compliance to auditors and regulators.
There is no universally correct answer. The right model depends on the organisation’s size, regulatory obligations, risk appetite, culture, and maturity. What matters is that the chosen model is deliberately designed, formally documented, and consistently followed.
This article examines three operating models — Centralized, Federated, and Hybrid — through the lens of governance, compliance, and audit readiness.
Three Operating Models Explained
Centralized Model
In a centralized operating model, a dedicated security team owns all security tooling, policies, pipeline security gates, and security decisions. Development teams consume security as a service — they receive scan results, remediation guidance, and pass/fail decisions from the central team.
Characteristics:
- Security tooling is selected, configured, and managed by a central team
- Security policies and gate criteria are defined and enforced centrally
- Exception approvals flow through the central security function
- Development teams have limited autonomy over security decisions
- Consistent control application across all teams and pipelines
Best suited for: Organisations with strict regulatory requirements demanding high consistency, or those in early DevSecOps maturity where central expertise compensates for limited distributed knowledge.
Federated Model
In a federated operating model, security champions are embedded within each development team. A central team sets overarching policy and standards, but individual teams are responsible for implementing security controls in their own pipelines and workflows.
Characteristics:
- Central team defines policy; teams implement independently
- Security champions within each team act as the primary security point of contact
- Teams may select their own tooling within approved boundaries
- Higher autonomy for development teams
- Risk of inconsistency across teams if governance is weak
Best suited for: Large organisations with mature development teams, strong engineering culture, and the capacity to train and support distributed security champions.
Hybrid Model
The hybrid operating model combines elements of both. A central team owns platform security, shared tooling, and policy definition. Embedded security champions handle application-level security decisions within their teams, operating within the boundaries set centrally.
Characteristics:
- Central team manages shared security infrastructure and platform-level controls
- Embedded champions own application-specific security within defined guardrails
- Shared responsibility model with clear boundaries
- Central oversight with local execution flexibility
- Requires well-defined interfaces between central and team-level responsibilities
Best suited for: Most regulated organisations seeking a balance between control consistency and delivery speed. This is the most common model in mature financial services and critical infrastructure organisations.
Detailed Comparison
| Dimension | Centralized | Federated | Hybrid |
|---|---|---|---|
| Control consistency | High — uniform enforcement | Variable — depends on team maturity | High for platform controls; variable for application controls |
| Scalability | Limited — central team becomes a bottleneck | High — scales with teams | Good — central scales platform, teams scale application security |
| Speed of delivery | Slower — central approvals required | Faster — teams self-serve | Balanced — platform decisions are fast, exception handling is structured |
| Expertise depth | Deep in central team, shallow in dev teams | Distributed but potentially shallow | Deep centrally, developing in teams through champions |
| Compliance alignment | Strong — easy to demonstrate uniform controls | Challenging — must prove consistency across teams | Strong — central oversight provides compliance backbone |
| Cost | High central team cost; lower distributed cost | Lower central cost; higher distributed training cost | Moderate — shared investment |
| Culture fit | Command-and-control cultures | High-trust, engineering-led cultures | Most organisational cultures |
| Audit complexity | Lower — single point of evidence collection | Higher — evidence scattered across teams | Moderate — central evidence plus team-level sampling |
Regulatory Context: Which Model for Which Framework?
DORA / Financial Services
DORA’s emphasis on ICT risk management frameworks (Article 6), testing (Articles 24–27), and third-party risk (Articles 28–30) demands consistent control enforcement and clear accountability. A hybrid or centralized model is typically most appropriate. The central function ensures uniform policy and oversight, while embedded champions can accelerate delivery without sacrificing governance.
Key DORA consideration: the management body must be able to oversee the ICT risk framework. This is significantly easier when a central team provides consolidated reporting.
NIS2 / Critical Infrastructure
NIS2 Article 21 requires “appropriate and proportionate” technical and organisational measures. For critical infrastructure operators, centralized models are often preferred because they provide the highest consistency and the simplest evidence trail for national authorities. The stakes of inconsistent control application are highest in this sector.
ISO 27001 / SOC 2
Any model can satisfy ISO 27001 or SOC 2 requirements, provided it is properly governed. ISO 27001’s Annex A controls and SOC 2’s Trust Services Criteria focus on whether controls are designed, implemented, and operating effectively — not on who implements them. The key is documentation and evidence of consistent application.
PCI DSS
PCI DSS’s strict requirements around segregation of duties, access control, and change management within the cardholder data environment (CDE) typically require a centralized or hybrid model for CDE-touching pipelines. A federated model introduces risk of inconsistent control application in a context where consistency is non-negotiable.
Governance Requirements by Model
Centralized Model Governance
- Central security policy covering all DevSecOps activities
- Service level agreements between central team and development teams
- Capacity planning to prevent the central team from becoming a delivery bottleneck
- Escalation procedures for urgent security decisions
- Regular stakeholder feedback to ensure the central model serves the organisation
Federated Model Governance
- Central policy framework with clear minimum standards
- Security champion selection criteria, training requirements, and performance standards
- Regular compliance assessments across all teams (not just self-assessments)
- Central oversight committee with authority to mandate remediation
- Standardised evidence collection templates to ensure audit readiness across teams
- Cross-team knowledge sharing and consistency reviews
Hybrid Model Governance
- Clear responsibility boundary document: what is central vs. what is team-level
- Shared RACI matrix (see DevSecOps governance resources)
- Central platform security standards and team-level implementation guidelines
- Exception management process that bridges central and team-level decisions
- Consolidated reporting that aggregates both central and team-level metrics
Transition Patterns: From Ad-Hoc to Structured
Most organisations do not begin with a deliberately chosen operating model. They evolve from an ad-hoc state — where security is handled inconsistently, often by whoever happens to care — to a structured model. Common transition patterns include:
- Ad-hoc → Centralized: The most common first step. Establish a central team to create order from chaos. Define policies, select tooling, enforce baseline controls.
- Centralized → Hybrid: As the organisation matures and the central team becomes a bottleneck, begin embedding security champions. Transfer application-level responsibility while retaining platform and policy ownership centrally.
- Hybrid → Optimised Hybrid: Refine the boundary between central and team responsibilities. Automate evidence collection. Establish metrics-driven improvement cycles.
Anti-pattern to avoid: Moving directly from ad-hoc to federated without first establishing strong central governance. Without a solid policy foundation, a federated model degenerates into continued ad-hoc operation with a governance label.
What Auditors Should Verify
When assessing an organisation’s DevSecOps operating model, auditors should evaluate the following:
Documentation
- Is the operating model formally documented and approved by management?
- Are roles, responsibilities, and boundaries clearly defined?
- Is there a governance charter or terms of reference for the DevSecOps function?
Evidence of Adherence
- Sample security decisions across multiple teams: were they made in accordance with the documented model?
- Are escalation paths used as documented?
- In federated or hybrid models: are security champions actually performing their designated role?
- Are there meeting records, decision logs, or workflow evidence showing the model in practice?
Consistency
- Compare security control application across three or more teams: are controls enforced consistently?
- Are there teams operating outside the defined model?
- Is the exception management process applied uniformly?
Red Flags for Auditors and Compliance Officers
| Red Flag | Implication |
|---|---|
| Documented model does not match observed practice | Governance is performative, not effective |
| Inconsistent control enforcement across teams | Federated or hybrid model is poorly governed |
| No central oversight of federated model | No mechanism to detect or correct deviations |
| No security representation in platform decisions | Security is an afterthought, not embedded |
| Central team is a persistent bottleneck with no mitigation plan | Model is unsustainable and drives shadow processes |
| Security champions exist in name only (no training, no time allocation) | Federated model is not resourced for success |
| No documented rationale for the chosen model | Model was not deliberately selected — likely inherited or accidental |
Next Steps
Choosing and governing an operating model is a foundational decision for any regulated DevSecOps program. Organisations should:
- Assess their current state honestly — is there a model, or is it ad-hoc?
- Select the model that fits their regulatory context, size, and maturity
- Document the model, including roles, boundaries, and escalation paths
- Implement governance mechanisms appropriate to the chosen model
- Review the model annually and after significant organisational changes
For further guidance, see our resources on DevSecOps program governance and security architecture.
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- NIS2 Security Architecture
- DORA Article 21 Deep Dive
- Dual-Compliance Architecture
New to CI/CD auditing? Start with our Auditor’s Guide.
