Federated architecture, security outside IT, and the container standard nobody owns
The meeting always ends the same way. The platform team wants to run production workloads on containers, and it asks a simple question: what are the rules? Who may open a shell inside a running pod? Must images be signed? May a container run as root? Is a hot fix inside a live container ever acceptable?
The security team answers: it is covered in the ISMS. The architecture team reads the ISMS again, line by line. It finds access control, change management, logging and hardening. It finds nothing about containers. Two weeks later, the same meeting happens again.
Both sides are right. That is the problem.
The setup is normal, and the friction is by design
In many enterprises, cybersecurity no longer reports into IT. In one Gartner Peer Community poll of 873 leaders, about half said information security reports via the CIO or CTO, and a third via the Chief Risk Officer. The reason for the separation is independence. The IIA Three Lines Model places information security among second-line roles that provide expertise, support, monitoring, and challenge to the first line, which owns and manages the risk. Critics of the old model put it bluntly: when security sits under the CIO, cost containment can outrank risk reduction.
So friction between architecture in IT and security outside IT is not a defect. It is the price of independence. Trying to remove it is the wrong goal. The job is to make it happen in the right forum, under rules agreed before the argument starts.
Two layers, two truths
An ISMS speaks in control objectives: access is restricted, changes are controlled, events are logged. A platform team needs technical standards: no kubectl exec into production except break-glass; images only from the approved registry, scanned and signed; containers run as non-root on read-only root filesystems.
Security is answering at the policy layer. IT is asking at the standard layer. Nobody names the layer, so the conversation loops.
Here is the useful part. The ISMS usually already requires the missing layer, in two places. If ISO/IEC 27001:2022 control A.8.27 is in your Statement of Applicability, principles for engineering secure systems must be established, documented, maintained, and applied to information system development. Control A.8.9 goes further: security configurations for hardware, software, services, and networks must be established, documented, implemented, monitored, and reviewed. A.8.27 can be met with technology-neutral principles. A.8.9 cannot be met without a configuration baseline for the platform you actually run. So the sentence to bring to security is not "you haven't written it". It is: "Our ISMS claims A.8.9 and A.8.27, and for containers we cannot show the evidence yet. Let's close that together."
The real gap is the protocol for having no standard
Containers are only the first case. Next come AI agents with tool access, service meshes, secrets in pipelines. If every new technology triggers a fresh case-by-case RACI debate, the organization pays the same negotiation cost again and again. Meanwhile, production runs without guardrails.
What is missing is a gap protocol: an agreed rule for who moves first when no standard exists. Mine fits in one line: IT holds the pen, security holds the stamp.
- The platform architect drafts an interim baseline by adopting references, not by inventing: "NIST SP 800-190 and the CIS Kubernetes Benchmark apply, with these deltas."
- Security architecture ratifies or amends it within a fixed time box, for example, ten working days. Ratifying a credible reference with a short delta is far easier than reviewing a home-grown document.
- The interim baseline carries an expiry, for example, six months. By then it becomes a formal standard owned by security, or it is replaced.
- During the interim, deviations go through the normal waiver process, because now there is something to deviate from.
Why should IT hold the pen? In most organizations, the platform team has the deepest knowledge of the orchestrator, the registry, and the pipeline. Waiting for principles hands the pen to the party least fluent in the technology. And the unguarded risk accumulates in IT's own estate while everyone waits.
Use case: eight starter principles for container platforms
NIST SP 800-190 organizes its countermeasures by image, registry, orchestrator, container and host OS, plus the container lifecycle. The starter set below follows that structure.
- Immutable by default. Production changes only through the pipeline. No shell or exec into production containers except a recorded break-glass procedure.
- Trusted provenance. Only scanned, signed images from approved registries. Admission control enforces this, not a manual review.
- Least-privilege runtime. Non-root, read-only root filesystem, no privileged mode, minimal Linux capabilities.
- Identity, not static credentials. Human access to the cluster API goes through SSO and RBAC. Administrative access goes through PAM with session recording. No long-lived kubeconfig files.
- Secrets never live in images. They are fetched from a vault at runtime.
- Default-deny east–west traffic, segregated by sensitivity. Workloads of different sensitivity do not share nodes or namespaces without explicit controls.
- Everything observable. Cluster API audit logs and runtime events flow to the SIEM.
- Hardened, minimal hosts. Container-optimized host OS, hardened to a recognized benchmark.
Principle 6 hides the next dispute. A Kubernetes NetworkPolicy is, in effect, a firewall rule, but it lives inside the platform and is written as code. If the rule says "all firewalls belong to security operations", who owns it? Settle this before the first incident does. Zone and perimeter firewalls stay with security operations. In-cluster policy belongs to the platform team as policy-as-code, against a default-deny baseline set by security, with security holding review rights on the repository.
Decision rights by class, not RACI by case
Case-by-case RACI debates are slow because each case is negotiated from zero. Peter Weill and Jeanne Ross made the point more than two decades ago in IT Governance: How Top Performers Manage IT Decision Rights for Superior Results (2004): governance means deciding in advance who holds the rights for each class of decision, not settling each decision as it comes. Agree the classes once, at executive level on both sides, then reuse them.
Situation | Holds the pen | Decides | Clock |
|---|---|---|---|
A. No standard exists | Platform / domain architect (interim baseline) | Security architecture ratifies or amends | Time-boxed review; interim expires |
B. Standard exists, guideline needed | IT | IT, security consulted | Normal delivery cadence |
C. Deviation from a standard | Requester | Risk owner accepts; security risk assesses | Assessment SLA; waiver expiry |
D. Integration with security-operated tools | Joint design | Security operations for the tool; IT for the integration | Planned in the project |
E. Dispute between A–D | Either side | A named joint forum | One meeting cycle |
The ideal RACI
Two rules make a RACI work: exactly one A per row, and the A sits where the consequence of the decision lands. C*below means consulted with required concurrence: the work cannot proceed without it, but the accountability does not move.
Activity | CISO office | Sec architecture | Sec risk mgmt | Sec operations | Enterprise architecture | Platform architect | Platform engineering | Risk owner | Internal audit |
|---|---|---|---|---|---|---|---|---|---|
Risk appetite and security policy (board approves) | A/R | C | C | C | C | I | I | C | I |
Security principles, including new tech domains | A | R | C | C | C | C | I | I | I |
Technical security standards and baselines | I | A/R | C | C | C | C | C | I | I |
Interim baseline when no standard exists | I | A | I | C | C | R | C | I | I |
Reference architectures and security patterns | I | C* | I | C | A | R | C | I | I |
Implementation guidelines | I | C | I | C | C | A/R | C | I | I |
Solution review against patterns | I | C (off-pattern only) | I | I | A | R | C | I | I |
In-platform controls (RBAC, admission, NetworkPolicy) | I | C | I | I | I | C | A/R | I | I |
Enterprise security tools (PAM, perimeter firewall, SIEM) | I | C | I | A/R | I | C | C | I | I |
Integrating the platform with security tools | I | C | I | R | I | A | R | I | I |
Detection and incident response | I | C | I | A/R | I | C | R | I | I |
Risk assessment of a deviation | I | C | A/R | C | I | C | C | I | I |
Risk acceptance (waiver) | I | I | C ("assessed by") | I | I | I | I | A/R | I |
Waiver tracking, expiry and remediation | I | I | A/R | I | I | I | R | R | I |
Independent assurance | I | I | I | I | I | I | I | I | A/R |
Note what this table refuses to do. Security never accepts risk on behalf of the business. Enterprise architecture never writes the security standard. The platform team never ratifies its own interim baseline.
What must be segregated, and why
ISO/IEC 27001:2022 lists segregation of duties as a control (A.5.3). In a federated model, these are the pairs that matter.
Keep apart | Risk if combined | Mitigation |
|---|---|---|
Writing a standard / accepting deviations from it | The standard bends quietly, one waiver at a time | Security writes; risk owner accepts |
Assessing a risk / accepting it | Assessment shaded toward the desired outcome | Security risk assesses; risk owner accepts |
Operating a control / verifying it | Nobody independent checks the operator | Second-line review or internal audit for security-operated controls |
Administering PAM / reviewing privileged sessions | Admins review their own sessions | Session review outside the admin group |
Requesting a waiver / approving a high-rated one | Owner signs off on their own high risk | Escalation by risk rating (below) |
Deploying / changing production outside the pipeline | Immutability becomes optional | Pipeline enforcement; break-glass needs a second person |
The waiver board: why security should not sign, and why it is not a moderator
A common design looks contradictory at first. The risk owner signs the acceptance. Security convenes the waiver board as a deployment gate, but does not sign as approver. So what is security doing there? Moderating?
No. The design is right. ISO/IEC 27001 requires risk owners to approve the treatment plan and accept residual risk. If security co-signed, accountability would blur ("security approved it"), and security would lose its independence: it would be grading a decision it helped make.
But a board where security has no binding role is theatre. In a healthy waiver board, security does five things:
- Assesses independently. A written residual-risk rating, in business-impact terms the risk owner can understand, not only a CVSS score.
- Challenges compensating controls. It verifies they exist and work, rather than accepting promises.
- Sets the conditions. Expiry date, mandatory compensating controls, remediation plan. A waiver without an expiry is a silent change to the standard.
- Triggers escalation. The rating decides who may accept. This is what gives security teeth without an approval signature.
- Records non-concurrence. If security disagrees and the owner accepts anyway, the disagreement is on the record.
An illustrative delegation of authority:
Residual risk rating | Who may accept | Maximum validity |
|---|---|---|
Low | Service owner (manager level) | 12 months |
Medium | Senior manager / VP | 6 months |
High | Executive / director | 3 months |
Critical | Risk committee, or not acceptable | Case by case |
Security's signature belongs on the form as "assessed by", never "approved by".
Two real contradictions remain, and they are worth looking for in your own organization. First, a waiver against a standard that does not exist is meaningless: the board can only block everything or waive everything. That is where the gap protocol and the waiver board meet. Second, when the waiver concerns a control security operates itself, such as a firewall or PAM exception, security is both a party and the gatekeeper. That class of waiver needs a second, independent reviewer, or at least a declared conflict of interest.
Design the interface, not the org chart
You probably cannot redraw the org chart, and the separation exists for good reasons. What you can design is the interface between the two sides:
- Name the layer: policy, standard, pattern, guideline.
- Agree on a gap protocol: the pen in IT, the stamp in security, a clock on both.
- Decide by class, not by case.
- One A per row, placed where the consequence lands.
- Segregate the pairs that matter, and only those.
- Give the waiver board teeth through rating-based escalation, not through security's signature.
Guardrails are not the opposite of speed. Undefined guardrails are.
When your organization meets a technology no standard covers, who moves first?
References
- The Open Group — TOGAF Series Guide: Integrating Risk and Security within a TOGAF Enterprise Architecture
- The Open Group — Integrating TOGAF and SABSA
- The IIA — Three Lines Model (2020)
- NIST — CSF 2.0 Core, Govern function (GV.RR)
- NIST — SP 800-190 Application Container Security Guide (ITL Bulletin)
- ISO/IEC 27001:2022 A.8.27 explained (Hightable)
- CSO Online — It's time to rethink CISO reporting lines
- Gartner Peer Community — Reporting line for information security (poll)
- Netflix — The Paved Road (Dianne Marsh)
- Peter Weill and Jeanne Ross, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results(Harvard Business School Press, 2004)
