Most guidance on secure architecture is about controls. This talk is about the relationship between the two groups of people who own those controls, and the specific ways that relationship breaks. Shana Dacres-Lawrence's thesis is that security and architecture are mutually dependent, that the dependency is maintained by contracts which are usually implicit rather than written down, and that the failures she encounters most often at that boundary come from one side quietly violating a contract the other side assumed was in force. She defines betrayal as the breaking or violation of a presumptive contract, trust, or confidence, and she means the word literally: her whole talk is structured as a relationship narrative between a personified Architecture and a personified Security.
Dacres-Lawrence is a senior architect who has moved repeatedly between security architecture and solution architecture roles across multiple industries in consultancy work, and is the founder of ArchitectHer. The framing matters because almost all of her evidence is either a first-hand account from those roles or a widely reported public incident — she is not presenting research results.
A note on the title: the InfoQ page titles the talk "to Betray One is to Destroy Both," while in the transcript she consistently says "to betray one is to betray both." The meaning is the same.
What You Will Learn
- Why security and architecture are structurally prone to conflict, and how their relationship has changed as systems moved from monoliths to distributed cloud architectures.
- Three recurring categories of failure at the security/architecture boundary, what each looks like from the inside, and a public incident illustrating each.
- Why "we discussed it with security" is not an agreement, and what to produce instead.
- Why an acquired company's security posture is an inherited liability rather than an inherited asset.
- Five defensive practices, which category of failure each one addresses, and why they only work applied together.
- Practical tactics for engineers who find their security team unapproachable or opaque.
How the Two Disciplines Got Here
Dacres-Lawrence opens with a potted history, delivered as a relationship arc. In early computing the two barely interacted: architecture was rigid and monolithic, focused on making things work; security was audit-driven and compliance-focused, with little scope beyond physical security. Architecture called security only when something had already gone wrong.
The internet boom of the early 2000s changed the threat surface. Architecture became microservice-driven and agile in order to scale to demand, while security became more proactive and adopted secure-by-design practices. Security began appearing inside architecture frameworks such as TOGAF. Her characterisation of this period is that the two were working together in practice without ever committing to it explicitly.
Today, she argues, the commitment is public and structural: zero trust as a default posture, DevSecOps embedded in delivery, threat modelling as shared practice. Architecture delivers scalability, resilience, and adaptability; security defends those same properties against breaches, downtime, and vulnerabilities. That is the healthy dependency. The rest of the talk is about what happens when it fails.
Physical Betrayal: Structural Weakness
Physical betrayal is her label for failures baked into the structure of the system. Her three sources are prioritising delivery over security, ignoring resilience principles, and misconfiguration.
The resilience point is worth separating out because it is the one engineers most often collapse into a single idea. She distinguishes the ability to withstand failure — availability, continuing to serve while degraded — from the ability to recover from failure, and she asks specifically how fast recovery happens. A system can score well on the first and catastrophically on the second. Misconfiguration is her third source, and her canonical example is the S3 bucket left on default settings: a failure that periodically disappears from industry discourse and then returns.
Her first-hand example: SMS as the primary authentication factor
Working as a security architect on a new identity solution for a customer, she found the software team wanted SMS as the core authentication method. Her security objection was that SMS is one of the weakest forms of multi-factor authentication because it is easily intercepted. The architecture position was that the customer base already knew SMS and the team already knew the integration patterns, so it would ship faster. Neither side moved, so the decision went to the business.
Both sides laid out their trade-offs, the business chose speed, and security was "left betrayed, left out in the open." She does not claim the business decided wrongly, and the escalation process itself worked as designed — the disagreement was surfaced, argued, and decided by the accountable party.
The public case: CrowdStrike
She uses the CrowdStrike outage as the large-scale version, and she is careful to note that CrowdStrike is itself a cybersecurity firm. That detail is load-bearing for her argument: betrayal at this boundary is not something architecture does to security, it is something either side can do, and here it was a security company that betrayed the integral structure of the systems it protected. Her account is that a security update process existed but was circumvented in order to ship faster, and the outage was attributed to flaws in that update process. She frames this as delivery prioritised over test assurance.
The figures she cites are 8.5 million Windows devices disabled, grounded flights, halted hospitals, and approximately $5.4 billion in recorded losses across Fortune 500 companies. She notes that one major airline reported losses of up to $500 million attributed to its own inability to recover quickly, and was pursuing action over it. Her emphasis is on the breadth of the blast radius — her phrasing is "from burger huts to broadcasting" — rather than on any single sector.
Note the recursion in the airline detail: the airline's damage was amplified by a resilience gap of its own, which is the same failure category one layer down. That connection is my reading of her two points together, not something she states explicitly.
Emotional Betrayal: Assumed Loyalty
Emotional betrayal is the failure of communication, and its signature is that one party believed there was an agreement when there was not. She is even-handed about who causes it. Security earns a reputation as the "no, no, no" function, reflexively blocking. Architecture and engineering supply a helicopter view of a design and deflect specifics with "it depends" or "that's an implementation detail," withholding exactly the context the security team needs. The result is misalignment that may be verbal or even documented, but was never actually agreed.
She adds a useful axis: which side holds disproportionate control varies by sector. In her public-sector work security tended to hold it and blocked quickly; in private-sector work the pressure to ship gave architecture and engineering the upper hand. Neither imbalance is healthy, and knowing which one you are operating under tells you which failure to expect.
Her first-hand example: the governance board
Before COVID, her team designed a solution using then-new cloud technologies. They circulated the design, consulted the people they were supposed to consult, and walked over to the security architects and security engineers to review it with them and take their improvement feedback. At the governance board, security was first to raise a hand and object that the design had multiple weaknesses.
She describes reflecting on this at home, and her partner asking why she had assumed security would be loyal — they had never said they would be. That was the epiphany she builds the category around: there had been a conversation, but no formal agreement. Consultation had been mistaken for consent.
The public case: Barclays
In January, on the first payday after Christmas — the 31st — the UK bank Barclays suffered a glitch lasting several days. Customers could not view balances, could not see online banking, and could not complete payments at checkout, forcing abandoned transactions and blocking payment for critical services. Balances displayed inconsistently. She reports the bank set aside $7.5 million in compensation, alongside significant reputational damage. (She states the figure in dollars for a UK bank; that is how it appears in the talk.)
She is explicit that the root cause was not published and that attributing it to misalignment and poor communication is her suspicion, not established fact. That qualification is worth preserving — this is the weakest-evidenced of her three public examples and she says so herself.
Trust Betrayal: Assumed Trust
Trust betrayal is her label for assuming a security property still holds without proving it, and she calls it the most dangerous of the three. The core mistake is treating a system's security and resilience posture as a fixed attribute when the system is changing daily. Under continuous deployment you are adding services continuously, and each addition compounds risk. The supporting conditions are insufficient proactive measures, insufficient testing, and insufficient third-party controls, usually rationalised with "we've never had a breach."
Her first-hand example: soft delete versus hard delete
Evaluating third-party vendors for a user-facing solution, her team had specific requirements on where data was retained, how it was deleted, and how it was archived. A vendor walked through how their product met those requirements. She had worked with that product before and knew the deletion was a soft delete rather than a hard delete, which would have breached the organisation's security posture. Her characterisation is that the vendor was "trying to get away on technicalities."
Supplementary context, not stated in the talk: a soft delete marks a record as deleted and hides it from normal reads while the data remains on disk and recoverable; a hard delete removes it. For data-residency and right-to-erasure requirements the difference is the entire requirement, which is why the distinction is worth interrogating explicitly in vendor assessments.
Her broader point is that this class of betrayal is only caught by someone with enough prior hands-on knowledge to challenge a plausible-sounding vendor claim — which is an argument for validation rather than for hiring luck.
The public case: Change Healthcare
Change Healthcare, a subsidiary of UnitedHealth Group, was acquired in 2022 and its systems were integrated. In her account, UnitedHealth assumed the acquired company adhered to the same security posture and controls it defined. In fact there was a server exposing an admin portal with no multi-factor authentication. Attackers reached that portal, moved laterally, and exfiltrated 4 terabytes of data, which she dates to April of the year before the talk.
The consequences she cites: critical healthcare and prescription payment services taken down across the US, 190 million people affected, the group CEO called before Congress, and a confessed ransom payment of $22 million in Bitcoin to recover the data. Her closing detail is that they were then held to ransom again over the same data. My own note: that second demand is the structurally expected outcome, because a ransom payment buys a promise to delete rather than the deletion of the attacker's copy.
The general lesson she draws is that an acquisition transfers the acquired company's actual security posture, not the acquirer's assumed one, and that integrating systems before verifying that posture merges the weaker perimeter into the stronger one.
Architecture And Data Flow
The talk does not describe a technical system architecture, so there is no architecture diagram to reproduce. What it does describe is a mapping from each betrayal category to the defences that counter it, which she states verbally as she introduces each defence. The diagram below is my own synthesis of those stated pairings — the diagram form is mine, the pairings are hers.
flowchart LR
PB["Physical betrayal
structural weakness"] --> TT["Tools and tech
shift left, fitness functions,
stand-in architecture"]
EB["Emotional betrayal
assumed loyalty"] --> OC["Open communication
explicit NFRs, no assumptions"]
EB --> CC["Collaborative culture
embedded security,
architecture advice process"]
TB["Trust betrayal
assumed trust"] --> AU["Automation
compliance and audit checks,
protected path to live"]
TB --> HV["Hands-on validation
pen tests, failover and
recovery testing"]Her caveat on this mapping is the important part. Applying the defences in isolation produced success against the targeted category and then betrayal on a different one; only applying all five and maintaining them as a consistent relationship between the teams produced durable results. Treat the arrows as where each defence has most effect, not as a decomposition into independent problems.
The other half of her framing is what the defences are for. Applied together, they replace assumed trust and assumed loyalty with proven trust: you stop assuming and put controls in place that demonstrate the property holds. Once you can prove it and validate it, you earn the next increment of trust between the teams, which is what makes the following round of proof cheaper. She is explicit that this is a cycle rather than a checklist — the five defences are the machinery that keeps the relationship being re-earned, not a set of boxes you tick once.
The Five Defences
Open communication
Both sides state their non-functional requirements explicitly — architecture's and security's — and actively eliminate assumptions: about the current security posture, about what the solution does, and about what failure conditions it must withstand. She adds positive reinforcement as a deliberate practice, on the grounds that reflexively negative framing degrades the channel you depend on. Her key tip is that consistency builds trust, because each side is watching to see whether the other's actions match its stated position.
Tools and tech
Invest in frameworks and tooling that integrate cleanly into the existing architecture and engineering workflow, so that adopting a control does not itself add complexity. Apply a zero trust mindset. Encode standards and patterns as executable checks — she names fitness functions in the codebase as the mechanism for holding development practices in place. She recommends investing in stand-in architecture, pointing at Monzo Bank's publicly shared approach as worth studying.
She attaches a communication requirement to this defence that is easy to skip: give security the full view of the system and the context for why the solution is being built the way it is, not the narrow slice needed to get a sign-off. Where teams present only the detail required to get through governance, security is left reasoning about a fragment, which is exactly the helicopter-view failure she describes under emotional betrayal.
Her key tip here is shift left: bring security and resilience practice into the software development cycle from the beginning, covering threat modelling through failure detection and reporting. She specifically recommends Failure Modes and Effects Analysis to identify where and how the solution can fail, how long the failure lasts, and how recovery happens, using that to set priorities.
Automation
Automate detection of and response to anomalies and breaches: domain blocking, workflows, compliance checks, audit checks, infrastructure and Terraform validation, deployment, and security patching. The objective is removing the dependency on a person being present to check and validate — the "always prove" half of zero trust.
The sharpest idea in this section is about the deployment pipeline. She quotes the line that if your path to live is broken you cannot get anything into production, and concludes that the path to live deserves the same protection as the production environment itself. Her key tip is to be intentional rather than transactional — find the areas where automation yields most and concentrate there, rather than automating uniformly.
Hands-on validation
Engage directly with the running system to confirm the design and security objectives actually hold: penetration testing, simulations, and failover testing. She repeats the withstand-versus-recover distinction here in operational form — test that data recovers and that systems recover, not merely that they survive. This is also where she places the explicit balancing of delivery speed against security, and a preference for proactive over reactive risk identification.
Her key tip is the honest one: you cannot test for every scenario, but you will have to react to every scenario. She pairs it with the advice to understand the scenarios that can occur in your system and know how you would react to each.
Collaborative culture
Her strongest recommendation is embedding security engineers and security architects inside engineering teams from the start of work, so each side develops working knowledge of the other's objectives. Security is reasoning about threat actors, risk, and how vulnerabilities propagate; seeing that reasoning first-hand is what turns security's "no" from an obstruction into an explicable position.
She also recommends the architecture advice process to ensure both security and architecture are consulted on decisions without either holding a veto, and a deliberately agile, open posture towards decision-making in which each side's point of view is actually weighed rather than merely collected. To that she adds reacting to change beyond your own engineering scope, because evolving external threats force security to revise positions that were adequate previously. Her key tip is the line the talk builds towards: security should guide architecture, but architecture should also shape security, and neither should exert too much control over the other.
Working With a Security Team That Feels Unreachable
The Q&A produced the most directly actionable material in the talk, largely from engineers describing dysfunction rather than designing for it.
Asked how to recover once a betrayal has already happened, she recommends reflecting on the cause first, then repairing the communication channel by asking directly what was missing — and formalising if the answer is that the agreement was only ever verbal. Concretely, she recommends decision documents recording the conversations held and the decisions made, which is what converts consultation into an agreement that can be pointed at later.
Asked by an engineer who finds security material genuinely difficult how to transfer knowledge between the teams, she suggested learning threat modelling directly, because it exposes the threat actors and risk derivation a security team reasons with. She then offered a reframe worth quoting the substance of: security teams are often defensive because they have been hurt — they are the ones who have had to stand in front of their superiors and explain what went wrong — and their reflexive blocking is a response to that experience rather than obstruction for its own sake.
Asked about security teams that behave as a "black hole," with briefings going in and nothing coming out, she gave a structural explanation: security teams are usually small while engineering is large and producing many components, so the same few people are spread thin across everything. Her practical answer was a standing weekly check-in — she ran an hour every Wednesday at 1pm — used to walk through developing ideas, design constraints, and security constraints early. The payoff is that by assurance time the security team already knows where the component came from and what thinking went into it, so review is not a cold read.
She does not leave the standing meeting carrying the relationship on its own. She pairs it with regular review cycles and with automation frameworks that let the team demonstrate it is adhering to the agreed security model and principles, so that proof of compliance flows continuously rather than only through the weekly conversation.
Trade-offs And Limitations
The evidence is experiential, not measured. Her three first-hand cases are individual incidents from her own consultancy career, and the public cases are reported incidents she is interpreting. The Barclays root cause in particular is her stated suspicion, not published fact. Her claim that the five defences work best together comes from her own experience of applying them, not from a controlled comparison. These are well-chosen illustrations of failure patterns, not evidence of the rate at which the patterns occur.
Escalation resolves decisions but not relationships. Her own SMS example ends with the business making a legitimate call against security's recommendation. The escalation itself worked, but the talk offers no mechanism for handling a correctly-decided outcome that still leaves a known structural weakness and a damaged relationship, neither of which the process records anywhere. Recording the decision, as her Q&A answer suggests, preserves the reasoning but does not remove the weakness.
Embedding security into engineering teams does not scale for free. She identifies the constraint herself — small security teams spread across large engineering organisations — and embedding is the most people-expensive of her five defences. In an organisation where that ratio is bad, the weekly check-in she describes is the affordable substitute rather than an addition.
Automation and validation cost delivery speed, which is the pressure that caused physical betrayal in the first place. She names balancing speed against security as part of hands-on validation but does not resolve it; the defences are disciplines to apply with judgment, not a policy that settles the trade-off.
Some ideas are pointers rather than instructions. Stand-in architecture, fitness functions, FMEA, and the architecture advice process are each named with a sentence of motivation and a recommendation to go and study them. Expect to do your own reading before implementing any of them.
Practical Takeaways
- Write down what security agreed to. After any design review with security, produce a decision record naming the concerns raised, what was agreed, and what was left open. This is the single control that converts assumed loyalty into an actual agreement.
- Book a standing weekly slot with your security team. Use it for in-flight designs and constraints, not for approval requests. It removes the cold read at assurance time and works when embedding is not affordable.
- Separate withstand from recover in your NFRs. State availability targets and recovery targets as distinct requirements, and test recovery — including data recovery — rather than inferring it.
- Treat the deployment pipeline as production. Apply the same access control, monitoring, and resilience requirements to the path to live, since it is the route through which you fix everything else.
- Run FMEA on the design before build. Enumerate how the solution fails, for how long, and how it recovers, and use that to order security and resilience work.
- Encode agreed standards as fitness functions. A check that runs in the pipeline survives team turnover and delivery pressure; a documented principle does not.
- Verify vendor claims against behaviour, not description. Ask specifically whether deletion is hard or soft, where data physically resides, and how archival works, and confirm it in the product.
- Treat an acquisition's security posture as unknown until proven. Verify before integrating systems, because integration merges perimeters.
- Notice which side holds disproportionate control in your organisation. Security-dominant environments fail towards blocked delivery; delivery-dominant environments fail towards structural weakness. Correct towards the middle.
- Learn threat modelling as an engineer. It is the cheapest way to understand how your security team derives risk, which is what makes their objections predictable rather than arbitrary.
Key Terms
- Non-functional requirement (NFR) — A requirement about how a system behaves rather than what it does; security posture, availability, and recovery time are all NFRs.
- Zero trust — A posture in which no request is trusted on the basis of network position or prior authentication, and every access is verified.
- DevSecOps — Integrating security practice and tooling into the development and deployment pipeline rather than applying it as a separate gate.
- Shift left — Moving a practice, here security and resilience work, earlier into the development cycle.
- Path to live — The full deployment pipeline from commit to production release.
- Fitness function — An automated, executable check that a system continues to satisfy a stated architectural characteristic; it fails the build when the characteristic degrades.
- Failure Modes and Effects Analysis (FMEA) — A structured technique for enumerating how a system can fail, what each failure affects, and how it is detected and recovered, used to prioritise mitigation.
- Stand-in architecture — Definition supplied here, not given in the talk: a design in which a degraded but functional fallback path takes over when the primary system is unavailable, so critical operations continue. Dacres-Lawrence cites Monzo Bank's publicly documented approach as the reference example.
- Architecture advice process — A decentralised decision practice in which the person making a decision must seek advice from those affected and from relevant experts, but retains the decision rather than requiring approval.
- TOGAF — A long-established enterprise architecture framework, cited by Dacres-Lawrence as a sign that security had started to appear formally inside architecture frameworks.
- Soft delete / hard delete — Marking a record deleted while retaining the underlying data, versus removing the data itself.
- Lateral movement — An attacker expanding from an initially compromised system into other systems inside the same trust boundary.
Her closing invitation is not to wait for a betrayal before reacting to it, and to audit which of the five defences you have naturally adopted versus which you have quietly skipped. The underlying claim is that security and architecture do not fail independently — a weakness introduced by one becomes an incident owned by both.
Reference: Shana Dacres-Lawrence, Security and Architecture: to Betray One is to Destroy Both, QCon London, published by InfoQ on March 27, 2026.