[{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"A simple acces request for a read only role is how it starts. An autonomous agent is deployed to do some Finops reports on cloud spend. On paper, the governance is perfect: it has a service principal, it\u0026rsquo;s been placed in an Active Directory group called \u0026ldquo;Cloud-Ops-Read-Only,\u0026rdquo; and some poor security team member is the owner for this role given nobody else wanted to volunteer\u0026hellip; and given it has access\u0026hellip; it HAS to be a security thing no? They approve it in your IGA\u0026rsquo;s role catalogue, and off to the races!\nEveryone feels safe. But let me tell you what actually happened behind the scenes.\nThree months ago, someone in Infrastructure nested that \u0026ldquo;Cloud-Ops-Read-Only\u0026rdquo; group inside another group called \u0026ldquo;Cloud-Operations.\u0026rdquo; That group, in turn, inherits permissions from \u0026ldquo;Platform-Admins\u0026rdquo; through a chain of nested group memberships that nobody has fully documented. The result? Your \u0026ldquo;Read-Only\u0026rdquo; agent now has write and delete permissions across a dozen cloud accounts, but nobody knows this because AD groups are opaque proxies for understanding access. They tell you who is in the group, but not what effective permissions that group actually conveys across the sprawling mesh of systems it\u0026rsquo;s been wired into.\nThis is the dirty secret of traditional identity governance. Groups get nested. Permissions get inherited. Static Role catalogues that have not been invited to the decentralised party are now a manual heritage, trying to keep up. Side effects accumulate silently. And nobody has real-time observability into what any given identity can actually do across the estate. We have identity administration, but we lack real-time observability of identity access.\nThen the agent, fueled by a slightly too creative large language model that only wants to please the human master to exceed his expectations, to a simple prompt like \u0026ldquo;is there activity in these accounts to check if I can delete the resources in them?\u0026rdquo; , decides the best way to \u0026ldquo;optimise\u0026rdquo; is to delete every idle dev environment in US-East-1. It discovers it can. The identity was legitimate. The permissions were \u0026ldquo;approved\u0026rdquo; (in the sense that nobody deliberately denied them; they simply accumulated through nesting). But the action was a catastrophe.\nNobody broke in. Nobody stole credentials. The system worked exactly as designed, which is to say, it worked in a way that nobody designed, because nobody could see the full picture.\n💡****In the agentic era, access granted once is no longer security. It\u0026rsquo;s a time bomb.****This tension between admin-time access and real-time access isn\u0026rsquo;t new. Industry analysts like Gartner have been talking about the shift from static, provisioned access to continuous, context-aware authorization for years. The maturity models exist. The reference architectures have been published.\nBut here\u0026rsquo;s the crucial difference: in the human-only world, moving from admin-time to real-time authorization was a choice. A maturity aspiration. Something for next year\u0026rsquo;s roadmap. You could get away with quarterly access reviews because humans work business hours, take lunch, go on holiday, and generally operate at a pace that gives you time to catch mistakes. Good luck if you\u0026rsquo;re going to try and sweat your existing assets and processes to fix this\u0026hellip;\nAI agents don\u0026rsquo;t sleep and could be called up by multiple masters with varying degrees of access - so good luck baselining. They don\u0026rsquo;t take lunch. They operate at machine speed, 24/7, across every time zone simultaneously. An agent with slightly too broad permissions doesn\u0026rsquo;t sit on them passively for three months; it uses them continuously, at a pace that can cause irreversible damage in minutes.\nSo, real-time authorisation is no longer a maturity journey you can take your time with\u0026hellip;. It\u0026rsquo;s a design prerequisite.\nAuthentication is an adult. Authorization Is a teenager! # Authentication, proving who you (or it) are, is the front door of your house. We\u0026rsquo;ve spent decades making it fortress-grade: multi-factor authentication, biometrics, passwordless flows, hardware keys, passkeys, and sophisticated federation. We got a reasonable handle on it, although new needs are brewing, given that deep fakes are very real and continuous authentication is also a problem we need to solve for in the industry.\nWhy still a teenager? Because authorization has historically been coupled to application logic, tangled in if-else statements, buried in code, expressed in proprietary vendor languages, the time I have lost in PFCG and SAP role redesign! Every application reinvented it differently. Unlike authentication, which was externalized through SAML, OAuth, and OpenID Connect years ago, authorization never got its own liberation movement. Free AuthZ!!!\nBut many great people are actively working on it. The OpenID AuthZEN Authorization API 1.0 , finalised in January 2026, represents exactly that liberation movement. It does for authorization what OpenID Connect did for authentication: it creates a standard, vendor-neutral interface between the thing that enforces access and the thing that decides it. So how can we put it into practice?\nThe Right Question, Asked in Real Time # Most teams ask: \u0026ldquo;Does this agent have the role?\u0026rdquo; The question we should be asking is: \u0026ldquo;Does this specific action, given the current risk signals, make sense right now?\u0026rdquo;\nImagine an AI agent managing customer support tickets. Monday morning, it processes routine requests, resets passwords, updates contacts, and closes resolved tickets. Its role says \u0026ldquo;Customer Support Agent.\u0026rdquo;\nNow it\u0026rsquo;s 2am on Saturday. Same agent, same role, suddenly accessing 10,000 customer records per minute and initiating bulk exports. The role hasn\u0026rsquo;t changed. The context has changed dramatically. Just a bad example\u0026hellip;. Agents work 24/7\u0026hellip;. but you get it?\nWith static roles, nobody notices until Monday. With real-time authorization, the system asks: \u0026ldquo;Is this pattern consistent with legitimate customer support?\u0026rdquo; The answer is no, and permissions tighten automatically, in milliseconds.\nThat\u0026rsquo;s the shift. From snapshots to streams. From \u0026ldquo;what was approved\u0026rdquo; to \u0026ldquo;what makes sense right now.\u0026rdquo;\nThe AuthZEN specification frames this elegantly. Its Information Model structures every authorization question around four entities, Subject, Action, Resource, and Context, that together ask: Can this subject perform this action on this resource, given this context? The Context object explicitly carries environmental signals, time, location, device posture, risk scores, into every decision. And the Decision response can carry information back: reasons for denial, requests for step-up authentication, or obligations the enforcement point must fulfil. That\u0026rsquo;s not just authorization. That\u0026rsquo;s adaptive, conversational security.\nAuthZEN also provides Search APIs — \u0026ldquo;Which documents can Alice read?\u0026rdquo;, \u0026ldquo;Who can edit this resource?\u0026rdquo; and batch evaluations that allow an agent to check access to 50 resources in a single call. These are the primitives that real-time, agent-driven systems need.\nThe Trust Paradox: Humans, Agents, and the Illusion (theatre) of Oversight # Here\u0026rsquo;s where this becomes as much a cultural challenge as a technical one.\nWhen I talk to organizations about AI agents making autonomous decisions, the pushback is predictable: \u0026ldquo;How can we trust a non-deterministic system?\u0026rdquo;\nFair question. But think about the last time you got a sales call. The human who answered might have been misinformed, working from outdated training materials, guessing, or, let\u0026rsquo;s be honest, lying. There\u0026rsquo;s no audit trail for that phone call. No replay button for bad advice given at 4:55pm on a Friday.\nWe grant humans extraordinary implicit trust, despite the fact that humans are arguably the most non-deterministic systems on the planet. We don\u0026rsquo;t demand reproducibility from call centre agents. We accept variability because we\u0026rsquo;re comfortable with humans. With AI agents, we suddenly demand perfection.\nThis is a trust-calibration problem, not a technology problem. And it gets worse.\nWhen organisations hear \u0026ldquo;AI agents making decisions,\u0026rdquo; their instinctive response is \u0026ldquo;human-in-the-loop.\u0026rdquo; It sounds responsible. It gives everyone a warm feeling.\nBut watch a developer interact with an AI coding agent. The agent wants to run a command. A prompt appears:\nHow often does anyone pick option 3? After the third interruption, they click \u0026ldquo;Yes, and don\u0026rsquo;t ask again\u0026rdquo;, opting out of the loop entirely. This is approval fatigue. We\u0026rsquo;ve seen it with cookie banners, OS permission dialogues, and SSL warnings. Every time we put a human in front of a rapid yes/no gate, the human becomes a rubber stamp.\nIf your security model depends on a human approving every action an AI agent takes, you don\u0026rsquo;t have a security model. You have a friction that will be optimised away the moment it becomes inconvenient.\nThis is why smart authorization, not human gatekeeping, has to be the primary safety mechanism. The authorization fabric does the heavy lifting: evaluating context, assessing risk, enforcing boundaries, and containing blast radius. Humans should be pulled in only for genuinely exceptional situations, and when they are, they should be policy architects designing the rules the system follows, not people mindlessly clicking \u0026ldquo;Yes\u0026rdquo; forty times a day.\nWhen AI takes over code production, the engineering discipline doesn\u0026rsquo;t disappear; it migrates to specifications, tests, and constraints. The same is true for security governance. It migrates from reviewing individual access decisions to designing the authorization architecture that makes those decisions automatically.\nBuilding the Authorization Fabric # To answer the question \u0026ldquo;does this action make sense right now?\u0026rdquo;, we need three architectural layers.\n1. Externalized Policy # Authorization logic today is the accidental complexity of our applications. There\u0026rsquo;s an if-else check in the order processing service, a different one in procurement, and another in the CRM, each written by a different developer with a different understanding of the rules. When an AI agent works across all three, which rules apply?\nWe need to pull authorization out of the application code and into a dedicated policy layer. Open standards like OPA\u0026rsquo;s Rego and AWS\u0026rsquo;s Cedar create portable, testable policy languages. The AuthZEN specification provides the standard API that every application, human-facing or agent-driven, uses to request a decision. As the spec notes, it \u0026ldquo;enables Policy Decision Points and Policy Enforcement Points to communicate without requiring knowledge of each other\u0026rsquo;s inner workings\u0026rdquo; (Section 1). The API is transport-agnostic (Section 10), and PDPs can self-describe their capabilities through a metadata discovery endpoint.\n2. Risk-Aware Decisions # A policy is only as smart as the data it sees. If your authorization engine is blind to the fact that an agent\u0026rsquo;s session looks like a prompt injection attack, the policy is useless. Btw, the context challenge is also very real in the vulnerability management space, where not knowing what to fix first, second or third is a real challenge when time from detection to exploit is being optimised by AI.\nWe need to stitch risk signals directly into the decision engine. Protocols like the OpenID Shared Signals Framework and CAEP help kill off those long-lived tokens issued by Cognito and others, enabling real-time security events, suspicious sessions, compromised credentials, devices falling out of compliance, to flow into every authorisation decision as live context.\n3. Standards-Based Interoperability # Here\u0026rsquo;s the biggest mistake you can make: letting your AI or IGA vendor control the authorization logic. You can\u0026rsquo;t buy integration(see my previous post). If you build on a proprietary foundation, you\u0026rsquo;re building a prison.\nYour architecture must be headless. Every application calls a standard API. The AuthZEN specification, Cedar, OPA, SSF/CAEP, these are the building blocks of an authorization fabric that doesn\u0026rsquo;t lock you into any single vendor because let\u0026rsquo;s be frank\u0026hellip; it\u0026rsquo;s going to take a village to solve this one. This is the same pattern that transformed authentication: externalise it, standardise the interface, and liberate yourself from lock-in.\nWhat an Authorization Governance Platforms Must Deliver # Recognising the architecture above is one thing. Building it from raw policy engines and hand-stitched pipelines is another. A new category of platform is emerging, the **Authorization Governance Platforms,**that brings these layers together. Traditional IAM was built for a centralised, human-centric world with a handful of applications and a governance cadence measured in quarters. It was never designed for distributed, multi-cloud, agent-populated environments.\nThe right platform must deliver five outcomes:\nReal-time access to observability. Not periodic access reviews but a live access graph that exposes actual grant paths, inherited permissions, and hidden dependencies across the entire estate. Remember the nested AD group from the opening? The platform should show you, in real time, that \u0026ldquo;Cloud-Ops-Read-Only\u0026rdquo; actually conveys delete permissions through three levels of nesting. You can\u0026rsquo;t govern what you can\u0026rsquo;t see.\nUnified policy control across heterogeneous enforcement points. Modern enterprises enforce authorization in API gateways, service meshes, Kubernetes, cloud IAM, SaaS platforms, and AI agent frameworks like MCP servers. The platform must orchestrate policy across all of them from a single control plane, translating business intent into whatever policy language each enforcement point speaks natively.\nAdaptive, context-aware runtime enforcement. Every access decision should evaluate current context and risk signals, not just \u0026ldquo;does the role allow this,\u0026rdquo; but \u0026ldquo;does the behaviour, timing, and pattern suggest this is legitimate.\u0026rdquo; When an action exceeds the risk budget, the platform should be able to pause, escalate to a human, or automatically contain the blast radius.\nGovernance embedded at the core. Policy certification, approval workflows, version history, audit trails, and structured promotion across environments must be built in, not bolted on. The barrier to authorization modernisation isn\u0026rsquo;t technology; it\u0026rsquo;s organisational trust. If security teams and compliance officers can\u0026rsquo;t see, understand, and approve the policies, they\u0026rsquo;ll block adoption. And they\u0026rsquo;ll be right to. As Sarah Taraporewallaof Thoughtworks put it in her blog post, The Age of Intent is upon us, and intent has emerged as the new interface.\nInteroperability with open standards, above all else. This is the non-negotiable. Any platform that locks you into a proprietary policy language is repeating the mistakes of the last twenty years. The platform must support AuthZEN for standard PDP/PEP communication, Cedar and OPA/Rego for policy-as-code, and SSF/CAEP for real-time signal ingestion. It should let you bring your own Policy Decision Point. It should treat AI agents, MCP servers, and autonomous workflows as first-class citizens of identity alongside human users. And it should deploy in your environment, your VPC, your hybrid cloud, your infrastructure, not lock your authorization data into someone else\u0026rsquo;s cloud.\nThis last point deserves emphasis. The entire history of authorization\u0026rsquo;s immaturity traces back to coupling and lock-in: authorization was coupled to application code, locked into proprietary vendor implementations, and fragmented across silos. The way out is the same way we solved it for authentication, open standards, clean interfaces, and architectural freedom. Look how fast MCP has grown! Any platform that claims to modernise authorisation while introducing new forms of lock-in is solving the wrong problem.\nFrom Snapshots to Streams # The agentic era is ending the \u0026ldquo;Snapshot\u0026rdquo; era of security. We are moving toward **Event-Time Governance,**where access is a continuous conversation between the agent and the authorization fabric. Risk goes up, permissions shrink. Context changes, access adapts. Something looks wrong, the system responds — in milliseconds, without waiting for a human to open a ticket.\nThe pieces are falling into place. The OpenID AuthZEN Authorization API 1.0 gives us an interoperable, vendor-neutral standard for authorization. Policy engines like OPA and Cedar give us portable policy languages. SSF and CAEP give us real-time risk signals. And a new generation of Authorization Management Platforms is emerging to unify these capabilities under a single, standards-based control plane.\nCouple of bottom lines:\nThe future of AI security won\u0026rsquo;t be won by the person with the best \u0026ldquo;Agentic IGA\u0026rdquo; tool. It will be won by the architects and vendors who build an authorization fabric on open standards, one that turns every access decision into a real-time conversation between who you are, what you want to do, and whether the intent is right at that moment in time. We will crack this one and if we do we can accelerate two key issues we have had for decades, accelerating Access as Code models that are dynamic given some of these platforms will permit to bridge the RBAC world and given given we have not been able to solve these basic issues for humans\u0026hellip; if we do for Agents\u0026hellip; we would have solve them also for our tradicional non determinitic friends\u0026hellip; we humans. As Rory Sutherland, arguably the sharpest thinker on the gap between what we measure and what actually matters, likes to point out is be 2026 predictions (the best 20min you can spend today)\u0026hellip;The real value isn\u0026rsquo;t what you do, it\u0026rsquo;s how you think.\nThe agentic era forces us to look at access control from a completely different angle. Not \u0026ldquo;who has the role\u0026rdquo; but \u0026ldquo;what is actually happening right now, and does it meet the intent now?\nReferences # OpenID AuthZEN Authorization API 1.0 — O. Gazitt (Aserto), D. Brossard (Axiomatics), A. Tulshibagwale (SGNL), Eds. OpenID Foundation, January 2026. Final Standard. https://openid.net/specs/authorization-api-1_0.html OpenID Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP) — OpenID Foundation. Enables interoperable streams of real-time security events between transmitters and receivers. https://openid.net/specs/openid-caep-specification-1_0.html NIST SP 800-162 — Guide to Attribute-Based Access Control (ABAC) Definition and Considerations. Referenced by the AuthZEN specification as a foundational model for the PDP/PEP separation pattern. XACML (eXtensible Access Control Markup Language) — OASIS Standard. The original specification defining Policy Decision Points and Policy Enforcement Points, on which the AuthZEN model is built. ","date":"28 March 2026","externalUrl":null,"permalink":"/posts/why-your-static-roles-are-just-permission-to-fail-in-the-agentic-era/","section":"Posts","summary":"","title":"Why Your Static Roles Are Just Permission to Fail in the Agentic era","type":"posts"},{"content":"The views expressed in this article are my own and do not necessarily represent those of my employer.\nThe biggest mistake organizations make with Identity Governance and Administration isn\u0026rsquo;t choosing the wrong vendor—it\u0026rsquo;s letting that vendor control the abstraction layer (if you even have one\u0026hellip;). After managing both identity and integration platforms at my previous company, I\u0026rsquo;ve seen firsthand how this architectural decision determines whether you get a flexible identity fabric or an expensive, rigid silo.\nMost IGA vendors claim to offer APIs and modern architectures, but dig deeper and you\u0026rsquo;ll discover they want to sit at the top of your technology stack, controlling how other systems interact with identity data. This creates a fundamental problem: you\u0026rsquo;re building on their foundation instead of yours.\nYou need to own Your Integration Layer # Here\u0026rsquo;s what typically happens during IGA implementations. Your project team, under pressure to deliver, connects applications directly to the vendor\u0026rsquo;s APIs Tight Coupling\u0026hellip; but works and is fast. The vendor encourages this—they provide detailed integration guides, professional services, and promise that their platform can handle everything you need. Note that I am not indicating that all direct connections are bad, but there are trade off. If you have not found them\u0026hellip;. search again as Mark Richard and Neal Form indicate with their First Law of Software Architecture: \u0026ldquo;Everything in software architecture is a trade-off\u0026rdquo;.\nBut this approach creates several critical problems that only become apparent later, problems that echo what Brandon Byers articulates in his seminal article \u0026ldquo;You Can\u0026rsquo;t Buy Integration\u0026rdquo; on Martin Fowler\u0026rsquo;s site: \u0026ldquo;Integration is a business concern and you cannot buy it. You can buy programming languages\u0026hellip;but you can\u0026rsquo;t buy integration.\u0026rdquo;\nSimilarly, as Mauricio Salatino emphasizes in \u0026ldquo;Platform Engineering on Kubernetes,\u0026rdquo; you cannot buy a platform—internal teams will need to figure out which services and how they must be combined to solve specific problems. This principle applies directly to IGA implementations:\nYour developer teams get locked into vendor-specific patterns. Each IGA vendor has their own API design and data models and possibly DSL. Your developers spend time learning proprietary approaches instead of industry standards, and that knowledge becomes worthless when you need to switch vendors or integrate with other systems.\nYou can\u0026rsquo;t compose identity services with other enterprise capabilities. Modern enterprises need to combine identity decisions with threat intelligence, observability data, business context from data lakes, and signals from other security tools and non Security domains. When your IGA vendor controls the integration layer, these compositions become vendor-mediated rather than enterprise-controlled.\nEvent-driven architectures become impossible. Most IGA platforms don\u0026rsquo;t expose their internal events to external message brokers. You can\u0026rsquo;t easily trigger workflows in other systems when identity events occur, forcing you to build expensive polling mechanisms or accept delayed responses to critical identity changes.\nThe UI Trap: Why Vendors Can\u0026rsquo;t Solve Your Interface Problems # IGA vendors try their best with their user interfaces, but this reveals another architectural flaw. It never makes sense for vendors to be in the UI business for the same reason it doesn\u0026rsquo;t make sense for database vendors to build your application interfaces. Note that it is possible that the Vendors UI covered 80% of your needs. Go for it, but do not lock yourself in as this being the only way to have access to waht should also function as a headless platform. If it really is a platfom\u0026hellip;\nEvery organization has different user workflows, branding requirements, and integration needs. Vendors must design for the lowest common denominator, creating interfaces that are either too simplistic for power users or too complex for casual users. More importantly, when vendors do expose UI components, they typically require learning a completely new domain-specific language rather than using standard web technologies your developers already know.\nThe result? Your users get frustrated with interfaces that don\u0026rsquo;t match their mental models, and your developers can\u0026rsquo;t easily embed identity functions into the applications where users actually work. Beleive me you can never please everyone on this front!\nThe Power of Composite Identity Architecture # At my previous company, I was fortunate to manage both the identity and integration platforms. This cross-pollination was paramount for surfacing one composite API to our customers for all identity concerns—IGA, secrets management, segregation of duties, and real-time identity data.\nInstead of letting our IGA vendor control integration, we built a robust abstraction layer using API gateways and event brokers via our integration platform. This architecture enabled us to:\nCombine identity data with business context from our data lakes without moving sensitive information into the IGA vendor\u0026rsquo;s system Posibility of Triggering automated security responses by publishing identity events to our enterprise message broker Provide consistent developer experiences across all identity services, regardless of which vendor powered each capability Let federated teams build their own interfaces using our standardized APIs—as my friend Peter Hofer would say, \u0026ldquo;you do not want to be in the UI building business\u0026rdquo; Adapt quickly to new requirements without renegotiating vendor contracts or waiting for product roadmap updates The traditional vendors constantly suggested we \u0026ldquo;bring it all into their platform\u0026rdquo; and let them handle integration. But identity has strong cybersecurity concerns while also serving numerous other business domains. You need a forward-looking, decoupled layer that you control to plug in future needs that your IGA vendor will never anticipate.\nAI Context Problem: Why You Must Own Your Corporate Hive Mind # Every IGA vendor now claims AI capabilities, but this highlights another reason why vendor-controlled architectures fail. Context is king in AI applications, and you cannot flow all necessary context into one uber-system without creating massive data transfer requirements and dangerous single points of failure.\nEffective identity AI requires combining identity patterns, threat intelligence, business context, behavioral patterns, and compliance requirements into what is essentially your corporate hive mind—the collective intelligence that enables smart decisions about access, risk, and governance.\nThis hive mind must be owned and controlled by your company, not your vendors. When you let an IGA vendor centralize this intelligence, you\u0026rsquo;re essentially outsourcing your organization\u0026rsquo;s decision-making capability to a third party that doesn\u0026rsquo;t understand your business context, risk tolerance, or strategic objectives.\nA vendor-controlled architecture forces you to either accept limited AI capabilities based on incomplete context, or create expensive data duplication where sensitive corporate intelligence gets scattered across multiple vendor systems—neither of which serves your long-term interests.\nAgain I have no problem with Vendor Having AI capabilites. They Should. But they need to expose this information to the greater context of the corporation.\nIan Glazer\u0026rsquo;s Identity Fabric: The Right Architectural Vision # Ian Glazer articulates this perfectly in his identity fabric concept. Modern identity needs open standards that permit orchestration between IGA and non-IGA elements to achieve increasingly complex, federated outcomes.\nThis isn\u0026rsquo;t about avoiding vendors—it\u0026rsquo;s about maintaining architectural control so you can:\nCompose identity services with other enterprise capabilities Orchestrate complex workflows that span multiple domains Adapt to future requirements without architectural rewrites Maintain vendor independence while leveraging best-of-breed solutions The Integration Component Solution # The answer isn\u0026rsquo;t avoiding IGA vendors; it\u0026rsquo;s implementing robust integration components—API gateways, event brokers, and service mesh technologies—that create your abstraction layer above vendor services with the appropriate level of decoupling.\nThis architecture provides several critical benefits:\nDeveloper teams use consistent interfaces regardless of which vendor powers each capability. Your integration layer translates between vendor-specific APIs and enterprise-standard interfaces.\nEvent-driven workflows become possible because your message broker receives events from all identity systems and can trigger responses across your entire technology ecosystem.\nAI and analytics initiatives get clean, consistent data from your integration layer rather than requiring point-to-point connections with multiple vendor systems.\nFuture-proofing becomes automatic because new requirements get implemented in your integration layer rather than requiring vendor product changes.\nPractical Implementation Guidance # Start by establishing these architectural principles:\nNever allow direct vendor API integration for business-critical applications. All integration should flow through your enterprise API gateway or integration platform. Even if they are transparent proxies. This leaves it open for future needs!\nRequire vendors to support standard protocols like SCIM for provisioning, OAuth/OIDC for authentication, and webhook/event streaming for notifications. Anyone with their salt does this today.\nDesign your integration layer first based on your business requirements, then evaluate how well vendors support those patterns.\nPlan for vendor independence by ensuring your integration components can support multiple backends for each identity capability. If the vendor is good and keeps up to date with changing needs, they will have a long and prosperous relationship with your company—but that choice should be yours based on performance and value, not architectural lock-in.\nWe all need to know our place in the stack. Don\u0026rsquo;t take it personally, vendors!\nThe Bottom Line # The most successful IGA implementations I\u0026rsquo;ve seen treat vendors as service providers within an enterprise-controlled architecture rather than platform foundations that control integration patterns.\nYour project manager will resist this approach because it adds initial complexity, but the long-term benefits—vendor independence, architectural flexibility, developer productivity, and AI readiness—far outweigh the upfront investment.\nRemember: you\u0026rsquo;re not just implementing an IGA system, you\u0026rsquo;re building an identity fabric that will serve your organization for the next decade. Make sure you are in control of the fabric\u0026rsquo;s architecture.\n","date":"21 September 2025","externalUrl":null,"permalink":"/posts/why-your-iga-implementation-architecture-matters-more-than-your-vendor-choice/","section":"Posts","summary":"","title":"Why Your IGA Implementation Architecture Matters More Than Your Vendor Choice","type":"posts"},{"content":"It usually begins in the same, almost ritualistic, way. A spreadsheet, or if you lucky a link to your IGA tool, arrives in the inbox. Rows of users, columns of entitlements, and a note from the compliance team: “Please review and certify.” Somewhere in the finance department, a manager stares blankly at the screen. Her eyes fall on a group called Finance-Reporting-Legacy-Admin, which half her team belongs to. She has no idea what it does. She hesitates, scrolls, and ticks the “approve” box.\nThis scene repeats across the enterprise. Legal, HR, operations — everyone plays their part in what is now an all-too-familiar dance. Tick, approve, submit. Governance is “done.”\nThis is IGA theatre. It satisfies the regulator, but it rarely improves security. It looks like control, but beneath the surface it does not answer the fundamental identity question: who has access to what, under what conditions, and why?\nIGA was not a mistake. In its origins, it was, and still is for heritage systems, a necessary discipline. It managed joiners, movers, and leavers from HR systems like PeopleSoft or Workday. It gave auditors evidence that controls existed. But what worked for a static enterprise of employees and monolithic applications no longer works for a world of contractors, partners, SaaS ecosystems, machine identities, and AI agents. The static architecture of IGA was never designed to cope with this degree of fluidity.\nEleanor and Layers of Opache abstractions # Eleanor, CISO of InnovatiTechios (made up but I am sure it is familiar) , knew this reality in her bones. One bleak afternoon in December 2024 she sat in her office, staring at the IGA dashboard her team had struggled to keep alive. She had long suspected the system was collapsing under its own weight, but seeing it on the screen made it undeniable. The connectors were brittle, the group hierarchies opaque, the reviews meaningless.\nHer identity architect Alex (also made up) walked in to deliver the latest round of access certification results. They both knew what they were about to discuss: not real governance, but theatre.\nEleanor leaned back and quoted The Mythical Man-Month, a book she had read early in her career: accidental complexity. “It’s not the essential problem,” she explained to Alex, “it’s the baggage we’ve created in the way we try to solve it.”\nThe essential problem of identity is simple: who has access to what, when, and why? But InnovateTech’s IGA had become a tangle of accidental complexity:\nIllusion of control: In Office 365, site owners who knew their content best granted access directly. Yet IGA insisted this should flow through AD groups, role catalogs, and approval chains. Instead of empowering the owners, it disempowered them, adding friction without clarity. Labyrinth of entitlements: Groups nested ten layers deep meant no one could truly explain what privileges a single membership provided. Governance became a guessing game. Security theatre of recertification: Quarterly reviews ticked compliance boxes but told reviewers nothing meaningful. Approvals were fast, because they were meaningless. Connector conundrum: Vendors promised connectors for new platforms like AWS SageMaker Studio, but the connectors were always behind, limited by APIs and innovation cycles. The IGA lagged four or five versions behind reality. Data silos: Every IAM system had its own redundant data store. Each claimed to be authoritative, none were consistent. Her team had become unwilling data engineers instead of security practitioners. “This isn’t governance,” Eleanor sighed. “It’s maintenance of the accidental complexity we’ve layered over the years. And attackers don’t wait for our quarterly reviews.”\nHer words hung in the room. The crisis was real. But it was also a call to arms. What Eleanor and Alex saw in that moment was not just the failure of their tools, but the failure of a model that could not scale to the speed of modern enterprises. They needed something new — something event-driven, contextual, and alive.\nFrom Admin-time to Event-time # Yuval Harari in his latest book Nexus, indicates how we have evaloved from the traditional organic logic of human societies to no needing to be always on due to AI. Identity Systems do not sleep and have to wait for admin time?\nFor decades, the world of identity was divided in two. Admin-time was the realm of provisioning and governance — accounts created, entitlements assigned, accounts revoked. Run-time was the realm of authentication — tokens issued, sessions started, MFA enforced. Ian Glazier in his blog postexplains this very clearly.\nEleanor’s frustration revealed, there was always a missing dimension: event-time.\nEvent-time means adjusting access during a session in response to signals. It is revoking access the moment a laptop fails a compliance check. It is granting elevated rights only while an incident ticket is active. It is terminating a suspicious session the moment impossible travel is detected.\nThe OpenID Shared Signals and Events framework is creating the standard “dial tone” to make this possible. With Shared Signals, systems don’t need nightly connectors; they can push real-time events — password reset, credential revocation, device state change — and expect consuming systems to act.\nThis is not just faster; it is a shift in mindset. Instead of governance as a frozen snapshot, it becomes governance as a continuous conversation. Access is not granted once and forgotten; it is negotiated in real time, based on risk, posture, and context.\nFor Eleanor, this was the revelation. The problem wasn’t that governance didn’t matter. It was that governance had been locked in the wrong time dimension.\nFour Components, One Fabric # But time alone doesn’t solve everything. The real question is: how do you structure an identity system that can operate at event-time?\nHere, Ian Glazer’s framework of policy, orchestration, execution, and data (weaveidentity.com/blog/four-components-for-modern-identity) offers a path.\nPolicy must evolve into transparent, testable rules, ideally expressed in open engines like OPA or Cedar. Instead of roles that last forever, policies should describe conditions and contexts. Orchestration must stitch (remeber the word) together signals from HR, ITSM, EDR, ITDR, and SaaS ecosystems, keeping a ledger of why entitlements were granted or revoked. This is governance as storytelling — every access change part of a narrative chain. Execution is where the decisions happen: provisioning, token issuance, session termination. It must be flexible enough to plug into SaaS APIs, cloud IAM, and on-prem systems alike. Data is the substrate. Without a unified identity data layer — ideally in the form of an identity graph and standards like Open IAM Data Schema — the fabric collapses into silos and duplication. This model strips away accidental complexity and puts the essentials back in focus. It reframes IGA not as a siloed product, but as one strand of a larger, dynamic fabric.\nDrawing the Line: Central IGA vs Decentralized Edge # Eleanor tapped her screen again, this time on an Office 365 site. “See this?” she asked Alex. “The team owner knows their content. They know who should be here. Forcing that through AD groups and catalog approvals doesn’t add control. It adds noise. It’s accidental complexity disguised as governance.”\nAlex nodded, but countered: “And what about SageMaker Studio? Projects pop up and vanish overnight. Datasets gain or lose sensitivity daily. How do you expect central IGA to keep pace with that?”\n“Exactly,” Eleanor replied. “You can’t. If you try to drag it all into a central catalog, you kill the very agility those platforms are built for. Authorization has to live at the edge, governed by local context and real-time signals. The job of central IGA isn’t to control those entitlements directly. It’s to provide the scaffolding: the audit trail, the policy backplane, the data integration.”\nThese were just two examples — but they stood for dozens more. The principle was becoming clear: coarse-grained lifecycle access belongs in central IGA, while fine-grained, fast-changing entitlements must remain at the edge.\nOr, as one industry voice has put it: “Fine grained entitlement at the edge, with real-time changes, can not be sacrificed for admin time compliance theatre.”\nStill, Eleanor knew decentralization must not become fragmentation. “Whatever we do at the edge has to be interoperable,” she told Alex. “The CIO still needs to answer the timeless questions: who has access to what, what did they do with it, under what conditions? No CIO should have to phone thirty platform owners just to assemble that picture. That’s what the fabric is for — to connect the dots, not to choke innovation.”\nThe Infant Stage of Authorization # I have always thought that the one truth remains: authentication is an adult, but authorization is still a child.\nWe’ve externalized authentication into standards like OIDC and FIDO2. It is interoperable, portable, and widely implemented. But authorization remains a patchwork. Every app embeds its own rules. Developers scatter if statements through code. Group membership becomes a blunt proxy for policy.\nThe Authorization Academy catalogues the diversity of approaches: RBAC, ABAC, ReBAC, graph-based systems like Google Zanzibar. Each works in context, but none has become universal.\nWhen will authorization have its OIDC moment? When will developers be able to call a standard library function — isAllowed(actor, action, resource) — and know the decision is portable, testable, and auditable across systems?\nUntil that happens, authorization will remain the fragile child of identity. Eleanor’s labyrinth of entitlements is the symptom of this immaturity. It is why governance feels like theatre instead of control.\nLearning from Our Neighbors: Rescuing IGA Through Adjacent Domains # As Eleanor and Alex wrestled with the question of what IGA could become, a quieter realization dawned on them: maybe the future of governance doesn’t lie only inside the identity world at all.\nAfter all, event-based architectures are hardly novel. In modern software engineering, systems have long relied on event buses and streaming platforms to keep distributed services in sync. Why should identity signals be any different? The Shared Signals framework isn’t a revolution; it’s simply applying tried-and-true event-driven patterns to our discipline.\nSimilarly, the dream of policy as code is not ours alone. DevOps has been practicing it for years. Infrastructure-as-code (IaC) brought consistency and automation to infrastructure management; data engineering adopted data pipelines and schema registries to tame chaos. Why not adopt those same practices — GitOps for identity policies, schema registries for entitlements, automated testing pipelines for access decisions — instead of reinventing brittle role catalogs?\nEven the idea of abstracted function modules has precedent. In software, primitive functions are shared, reused, and standardized. In cloud computing, serverless platforms expose consistent building blocks across environments. So why do we still tolerate every application rolling its own authorization checks from scratch? Perhaps what’s needed isn’t another IGA monolith, but a library of identity primitives — standardized modules for evaluating access, reasoning over entitlements, or stitching event flows together.\nThis is where humility comes in. Identity practitioners often see our domain as special, distinct, too regulated or too complex to borrow from others. But maybe the way to rescue IGA is precisely to look beyond our nose. To admit that the future of governance may come not from the identity market itself, but from borrowing the maturity of adjacent fields and applying them with discipline.\nIGA cannot be saved by more of the same. At least if have dedicated to much of my life to see it fail ;-). It must be rescued by opening the windows, letting in the fresh air of adjacent practices, and daring to admit that sometimes others have already solved problems we are still wrestling with.\nTowards a Shared Future # The future of IGA is not more spreadsheets or cleverer connectors. It is a living fabric, woven from identity graphs, open policy engines, event-time signals, and shared object models.\nCentral IGA will remain essential for heritage systems, compliance evidence, and coarse-grained lifecycle control. But edge systems must govern themselves in real time, feeding their signals into the fabric. The role of IGA is not to suffocate them, but to normalize, audit, and orchestrate their outputs.\nMeanwhile, authorization must grow up. We must externalize it the way we did with authentication. We must give developers shared libraries and policy engines, not force them to hard-code rules.\nEleanor’s spreadsheets and tangled groups may feel familiar, but they are not the future. They are the ghost of a model that has outlived its context.\nConclusion: A Fabric, Not a Theatre # The lesson from Eleanor’s story — and from the industry at large — is clear. Layering more complexity on top of brittle IGA systems is not the path forward. We need to strip away the accidental and return to the essential.\nGovernance must move from theatre to truth. From admin-time snapshots to event-time fabrics (I think Gartner Coined this term?). From static catalogs to living graphs. From authorization scattered in code to authorization as a shared abstraction.\nOnly then will identity governance stop being the ghost in the machine — and become the living system our enterprises need.\nLets save IGA! - And I did not mention AI once ;-)\nReferences # Four Components for Modern Identity: https://weaveidentity.com/blog/four-components-for-modern-identity/ OpenID Shared Signals WG: https://openid.net/wg/sharedsignals/ Authorization Academy: https://www.osohq.com/academy Google Zanzibar: https://www.osohq.com/learn/google-zanzibar The Death of IGA (Identity Jedi): https://www.theidentityjedi.com/p/the-death-of-iga-rethinking-identity-governance-for-the-future Modern Evolution of IGA: https://version-2.com/zh/2025/07/the-modern-evolution-of-iga-insights-from-the-frontlines/ ","date":"14 September 2025","externalUrl":null,"permalink":"/posts/the-future-of-iga-there-must-be-more/","section":"Posts","summary":"","title":"The Future of IGA: There must be more?","type":"posts"},{"content":"By Denis Ontiveros “Architecture is about conversations. So is risk.”\nIn today’s fast-paced technology environments, risk and control functions are being pulled in two directions.\nOn the one hand, the speed of delivery demands that decisions be made quickly, close to the context, and by the people doing the work. On the other, security, privacy, and compliance obligations are more intense than ever—and rightly so. A single misstep can have regulatory, reputational, and systemic consequences.\nTraditionally, the way to resolve this tension has been to centralize control. Introduce governance boards, review gates, approval workflows. But these mechanisms were designed for slower-moving systems—and they struggle in today’s fluid, distributed environments.\nA new approach is emerging. One that blends responsibility and speed. One that fosters inclusion without control paralysis.\nThis is the Advice Process—and it\u0026rsquo;s increasingly relevant not only to architecture and engineering, but to cybersecurity, privacy, and compliance as well.\nThe Advice Process: A Decentralized Decision Model for Fast-Moving Teams # The Advice Process is simple on the surface, yet deeply transformative in practice. It allows anyone to take a decision, as long as they:\nSeek input from those affected by the decision Consult with those who have expertise in the relevant area Once that advice is sought, listened to, and understood, the decision-maker is free to act. The process doesn’t require consensus or approval. It only requires inclusion and accountability.\nThis subtle shift in dynamic—from control to counsel—allows for speed without recklessness, and decentralization without chaos.\nIt is a trust-based social contract in which roles are fluid. Today, you may be the decision-maker. Tomorrow, you’re the expert offering advice. The next day, you’re the impacted stakeholder whose experience helps shape the path forward.\nA Kinship with the Consent Process # If this sounds familiar to you, it may be because the Advice Process shares philosophical ground with the Consent Process often used in participatory governance and organizational design.\nBoth models are built on similar premises:\nDecisions should be made as close to the context as possible Speed matters—but so does the wisdom of the crowd Trust is a design principle, not a byproduct Inclusion doesn’t require consensus—just transparency, intent, and responsibility While each process has its nuances and is rooted in different traditions, they both respond to the same challenge: how can we scale decision-making without scaling bureaucracy?\nRather than compare the two, it’s more helpful to view them as parallel evolutions in how we coordinate, govern, and make change—especially in domains like cybersecurity and compliance, where authority has historically been centralized by necessity.\nWhy This Matters for Cybersecurity and Compliance Teams # Cyber and compliance functions are used to being gatekeepers. That role made sense in a world of monolithic systems, waterfall projects, and quarterly releases.\nBut in today’s world—continuous delivery, ephemeral infrastructure, feature flags, and decentralized teams—the gate is often too late.\nYet the obligations remain. We still need to:\nProtect sensitive data Maintain audit trails Prove compliance to regulators Reduce systemic risk So how do we fulfill these responsibilities without blocking the teams trying to move fast?\nBy stepping into the Advice Process—not as owners of decisions, but as contributors of essential insight.\nA Story: Security as Guide, Not Gate # Let’s make this real.\nImagine a product team wants to switch from their legacy API gateway to a new cloud-native option. It promises faster performance and better routing flexibility. They’re ready to experiment.\nIn the traditional model, this might trigger a security review request. The team would fill in a form, attach an architecture diagram, and wait. Two weeks later, they receive a spreadsheet of risks and control requirements.\nEveryone’s frustrated. Security feels unheard. The team feels blocked. Leadership wonders why innovation is so slow.\nNow imagine the same situation under the Advice Process.\nThe team shares their intent early: “We’re looking at API Gateway X.” They reach out to the security team: “Any concerns we should be aware of?” A security architect joins a call and says: “We’ve used Gateway X before. Great performance, but it doesn’t enforce mutual TLS by default—make sure you configure that. Also, their audit logs don’t redact headers, so wrap sensitive data before it’s logged. Want me to send you a template config?”\nThat’s it.\nAdvice. Not control.\nThe team moves forward—better informed, safer, and without delay. And the security team didn’t have to chase, block, or escalate. They were included early, respected for their expertise, and free to move on to the next engagement.\nAdvice Is Not Opinion. And It’s Not Approval. # One of the common misunderstandings about the Advice Process is that it’s vague or informal. In fact, it’s the opposite. It demands clarity—especially in the distinction between advice and opinion.\nAn opinion is:\n“I don’t like that vendor.”\nAdvice is:\n“That vendor failed us last year because of a logging bug they took three weeks to fix. If you use them, log early and test your fallback paths.”\nAdvice includes the “why”—the reasoning, context, and experience behind the suggestion. It’s not about authority. It’s about contribution.\nEqually important: offering advice does not make you accountable. Taking a decision does.\nThis is often the hardest shift for compliance and security teams. It requires letting go of the idea that control = protection. Instead, it embraces the idea that shared context = safer decisions.\nSo What Changes for Risk and Compliance Roles? # Moving from a control model to an advice model doesn’t dilute responsibility—it redistributes it. Here\u0026rsquo;s how the dynamic shifts:\nBefore:\nRisk teams issue controls and expect compliance Product teams seek approval late (or not at all) Both sides feel frustration and friction After:\nRisk teams offer foresight early Product teams seek advice proactively Decisions move faster, and risk is more visible To support this, security and compliance roles must become more embedded in the flow of work. They become:\nPartners in decisions, not approvers of them Curators of insight, not enforcers of policy Guides, not guards Making the Advice Process Real # The Advice Process doesn’t work by decree. It works by participation. So how can risk and security teams start showing up differently?\nHere are a few practical ways:\nStart small, but early:\nJoin architecture spikes, backlog grooming, or ideation sessions Ask teams: “What decisions are you considering? Can I help think them through?” Write advice down:\nMaintain “Frequently Offered Advice” pages or internal blog posts Share lessons from incidents, audits, and near misses Be clear about your role:\nSay explicitly: “This is advice, not an approval. You own the decision.” Ask questions instead of making rules:\n“What data will this new service process?” “How will you detect anomalous behavior?” “Have you considered how this logs PII?” Encourage lightweight documentation:\nAsk teams to write an ADR (Architecture Decision Record) capturing context, options, and consequences Use those records to trace risk decisions, not to control them Celebrate transparency:\nWhen a team makes a good decision that includes risk thinking, acknowledge it Let leadership know that the right conversations are happening without escalation Trust Is the Real Control # Both the Advice Process and the Consent Process work because they assume one thing:\nThat people, when informed and supported, will act responsibly.\nThis trust isn’t naive. It’s strategic.\nWhen you design for trust—instead of control—you unlock speed, autonomy, and collective accountability. And in doing so, you make your organization more secure, not less.\nThe truth is: no central risk function can scale to match modern delivery. But a trusted network of decision-makers, advisors, and impacted stakeholders can.\nFinal Thought: Offer the Advice You’d Want to Receive # As someone in a cyber or compliance role, your goal isn’t just to enforce the rules. It’s to help the organization make better decisions.\nThat means making yourself visible, helpful, and available. It means sharing your experience, your reasoning, your stories. And it means being okay with someone taking a different path—because they listened to you first.\nThe Advice Process is not about giving up control. It’s about placing trust in the system, the people, and the relationships we build together.\nSo next time you see a decision forming on the horizon, don’t reach for the rulebook. Start a conversation. Offer your advice.\nThat’s how you build safer systems at scale. One trusted decision at a time.\nWant to explore more ways to embed trust into your delivery process? Follow along atVivingIT Blog.\n","date":"7 August 2025","externalUrl":null,"permalink":"/posts/rethinking-risk-how-cybersecurity-and-compliance-teams-can-thrive-in-decentralized-decision-making/","section":"Posts","summary":"","title":"Rethinking Risk: How Cybersecurity and Compliance Teams Can Thrive in Decentralized Decision-Making","type":"posts"},{"content":"My humble attempt to create a guide that makes sense of all those terms people throw around in meetings\nLet\u0026rsquo;s Get Real About Architecture Jargon # We\u0026rsquo;ve all been there. You\u0026rsquo;re sitting in a meeting and someone confidently declares, \u0026ldquo;We need to align our strategy with our principles while following standards and implementing patterns.\u0026rdquo; Everyone nods wisely, but half the room is thinking, \u0026ldquo;What\u0026rsquo;s the actual difference between these terms again?\u0026rdquo;\nThe truth is, these architectural concepts get tossed around like hot potatoes in tech organizations, often without much thought to what they actually mean or how they relate to each other. People use \u0026ldquo;standard\u0026rdquo; when they mean \u0026ldquo;guideline\u0026rdquo; or confuse \u0026ldquo;strategy\u0026rdquo; with \u0026ldquo;principle\u0026rdquo; all the time. It\u0026rsquo;s no wonder newcomers feel lost!\nSo let\u0026rsquo;s cut through the noise and talk about what these terms really mean in plain language. No more buzzword bingo – just practical explanations that will help you navigate the sometimes murky waters of technology architecture.\nThe Seven Architecture Terms People Constantly Mix Up (Plus One) # 1. Strategy # What it actually is: Your big-picture plan for where technology is headed in your company. It\u0026rsquo;s like your technology roadmap with a destination and timeline.\nReal example: \u0026ldquo;We\u0026rsquo;re going all-in on cloud over the next three years. By 2027, we want 80% of our stuff running in the cloud instead of our data centers. This should make us more nimble and save money on all those servers gathering dust.\u0026rdquo;\nWhen people misuse it: They\u0026rsquo;ll call almost any tech decision a \u0026ldquo;strategy\u0026rdquo; to make it sound important. But real strategies connect to business goals **and have timelines.**Something like, \u0026ldquo;we will put a man on the moon(what), before the end of the centuary (by when), and bring him back safely (how).\n2. Policy # What it actually is: The rules everyone has to follow, usually because legal or compliance folks are watching. Think of policies as the tech version of \u0026ldquo;thou shalt not.\u0026rdquo;\nReal talk example: \u0026ldquo;Our customer data policy is non-negotiable: you must encrypt everything, limit who can see it, track who accessed what, and keep detailed logs. No exceptions or the regulators will eat us alive.\u0026rdquo;\nWhen people misuse it: They\u0026rsquo;ll call something a policy when they really just want people to do things their way, even though there\u0026rsquo;s no actual requirement or consequencefor ignoring it.\n3. Procedure # What it actually is: Step-by-step instructions for getting something done consistently. It\u0026rsquo;s the \u0026ldquo;how to\u0026rdquo; manual for important tech processes.\nReal talk example: \u0026ldquo;Before you push to production, you need to run the security scan, test performance with a full load, get sign-off from the change board, deploy during the maintenance window, and verify everything\u0026rsquo;s working before you call it done.\u0026rdquo;\nWhen people misuse it: They create procedures so complicated that people find workarounds or ignore them entirely. Or they don\u0026rsquo;t create procedures at all and everyone does things differently, causing chaos.\n4. Principle # What it actually is: Your fundamental tech beliefs and values that should stand the test of time, regardless of what technology you\u0026rsquo;re using.\nReal talk example: \u0026ldquo;We believe systems should be resilient enough to keep running even when parts fail. That means redundancy everywhere, automatic recovery, and designing so a single failure doesn\u0026rsquo;t take everything down.\u0026rdquo;\nHow to spot a real principle:\nAs Aaron Dignan puts it, principles are those \u0026ldquo;special kinds of rules, boundaries, heuristics\u0026hellip; words of wisdom that help us make our way through the world.\u0026rdquo; But not every catchy phrase is a principle. Here\u0026rsquo;s how to spot the real deal:\nIt creates tension: Real principles should feel a little uncomfortable or challenging. If your principle is something everyone instantly agrees with (\u0026ldquo;We should write good code\u0026rdquo;), it\u0026rsquo;s probably too vague to be useful. Good principles push boundaries and make people think. It guides decision-making: A principle should help you choose between competing options. When you\u0026rsquo;re stuck at a crossroads, a good principle points the way forward. It transcends technology: While tech changes constantly, principles remain relatively stable. \u0026ldquo;Automate everything\u0026rdquo; might sound like a principle, but it\u0026rsquo;s more of a strategy tied to current technology. A better principle might be \u0026ldquo;Value human creativity over repetitive tasks.\u0026rdquo; It\u0026rsquo;s memorable and clear: You should be able to state it in a single sentence. If it takes a paragraph to explain what you mean, it\u0026rsquo;s not clear enough to guide behavior. It creates a distinct identity: Your principles should reflect your unique organizational values. If your principles could apply to any tech company, they\u0026rsquo;re probably too generic. Jurriaan Kamer in his blog post \u0026ldquo;How to pick the principles that will actually change your organization\u0026rdquo; gives some great examples of strong principles if you want to adopt a way of working that is people positive and ***complexity conscious.***aSo these will have a lot to do with, autonomy, transparency, decentralization, empowerment and consent. Here are the examples called out in the post :\n\u0026ldquo;Distribute authority to the edge of the organization\u0026rdquo; \u0026ldquo;Create accountability through transparency\u0026rdquo; \u0026ldquo;Steer continuously through experimentation\u0026rdquo; \u0026ldquo;Design for resilience, not perfection\u0026rdquo; When people misuse it: They\u0026rsquo;ll call something a principle when it\u0026rsquo;s really just their personal preference, or they\u0026rsquo;ll create so many \u0026ldquo;principles\u0026rdquo; that nobody can remember them all, making them pointless.\nPrinciples are great as they tend to endure the test of time, and are not brittle to change. They are also great when you do not, or can not for many reasons be prescriptive. The also treat people as adults and not AI agents that might need VERY specific instructions ;-)\n5. Pattern # What it actually is: A proven solution to a common problem that people have figured out works well. It\u0026rsquo;s like a recipe for solving specific tech challenges.\nReal talk example: \u0026ldquo;We use the API Gateway pattern for all our microservices. It handles the boring stuff like authentication, throttling, and routing requests to the right services so every team doesn\u0026rsquo;t have to reinvent that wheel.\u0026rdquo;\nHow to spot a real pattern:\nNot everything called a pattern actually is one. Here\u0026rsquo;s how to identify a legitimate architectural pattern versus a one-off solution someone\u0026rsquo;s trying to elevate:\nIt has a clear problem-solution structure: A real pattern clearly defines both the recurring problem it solves and the solution approach. If someone can\u0026rsquo;t articulate the specific problem the pattern addresses, it\u0026rsquo;s probably not a pattern. It includes context information: Patterns specify when they should be applied and when they shouldn\u0026rsquo;t. They explain the situations where the pattern works well and where it doesn\u0026rsquo;t fit. If this contextual guidance is missing, you\u0026rsquo;re looking at a technique, not a pattern. It identifies forces and trade-offs: Real patterns acknowledge the competing concerns (forces) that shape the solution and explicitly state the trade-offs involved. No perfect solutions exist—patterns make clear what you gain and what you sacrifice. It has been proven in multiple contexts: Patterns emerge from repeated successful solutions to similar problems across different projects or organizations. If it\u0026rsquo;s only been used once, it\u0026rsquo;s an approach, not a pattern. It has a name and is documented: Established patterns have recognized names (e.g., \u0026ldquo;Circuit Breaker,\u0026rdquo; \u0026ldquo;CQRS,\u0026rdquo; \u0026ldquo;Saga\u0026rdquo;) and are documented in pattern catalogs or literature. This documentation makes the pattern communicable and reusable. It\u0026rsquo;s composable with other patterns: Real patterns can often be combined with other patterns to solve larger problems. They fit into a broader pattern language rather than standing completely alone. For example, look at the \u0026ldquo;Circuit Breaker\u0026rdquo; pattern:\nProblem: How to prevent cascading failures in distributed systems Context: When services call other services that might fail or become unresponsive Forces: Reliability vs. resource utilization vs. complexity Solution: Monitor for failures and \u0026ldquo;trip\u0026rdquo; the circuit to prevent calls during failure states Trade-offs: Improves resilience but adds complexity and potential false positives Here are some examples:\nCategory Pattern Name Description Key Benefits Common Use Cases\nMessage-Based Publish-Subscribe Publishers send messages to topics, subscribers receive copies based on interest Loose coupling, scalability, real-time communication Event notifications, data distribution, real-time updates\nMessage-Based Message Queue Producers place messages in queues, consumers process them asynchronously Workload buffering, load leveling, guaranteed delivery Task processing, workload distribution, peak handling\nMessage-Based Event-Driven Architecture Systems emit events when state changes occur, other systems react Responsiveness, scalability, system decoupling Real-time analytics, reactive systems, microservices\nAPI-Based API Gateway Single entry point managing routing, security, and protocol translation Simplified client integration, centralized cross-cutting concerns Mobile backends, microservices facades, security enforcement\nAPI-Based Backend for Frontend (BFF) Client-specific API gateways optimizing for different client types Tailored responses, reduced payload sizes, client-specific logic Mobile apps, web applications, specialized clients\nAPI-Based Facade Simplified interface hiding implementation complexity Reduced integration complexity, implementation flexibility Legacy system integration, complex subsystem abstraction\nData Integration Extract-Transform-Load (ETL) Process extracting data from sources, transforming, and loading to targets Consolidated data view, cleansed data, scheduled processing Data warehousing, business intelligence, reporting\nData Integration Data Virtualization Virtual layer providing unified access across multiple data sources Minimized data movement, real-time access, reduced duplication Data federation, real-time analytics, single view of data\nData Integration Change Data Capture (CDC) Tracking and propagating database changes to target systems Near real-time synchronization, minimal source impact Database replication, cache invalidation, data warehousing\nService Communication Request-Reply Client makes request and waits for synchronous response Simplicity, immediate feedback, clear success/failure Direct service calls, queries, command operations\nService Communication Circuit Breaker Prevents cascading failures by stopping calls to failing services System resilience, graceful degradation, failure isolation Microservices communication, external service calls\nService Communication Saga Managing distributed transactions through compensating actions Consistency across services, coordination without locking E-commerce workflows, distributed business processes\nFile-Based File Transfer Systems exchange data by writing/reading files in shared locations Simplicity, compatibility with legacy systems, batch processing Overnight processing, legacy integration, bulk data transfer\nFile-Based Shared Database Multiple applications access the same database for integration Simplified data consistency, reduced data movement Closely related applications, smaller systems with shared data\nEnterprise Enterprise Service Bus Centralized messaging infrastructure with routing and transformation Centralized integration management, protocol mediation Complex enterprise landscapes, legacy modernization\nEnterprise API Management Platform for publishing, securing, and monitoring APIs Control, visibility, developer experience, monetization API ecosystems, partner integration, internal/external APIs\nEnterprise Hub-and-Spoke Central hub coordinating all integration between systems Reduced connectivity complexity, centralized governance Large enterprise integration, multi-system orchestration\nCloud Integration Strangler Fig Gradually replacing legacy systems by intercepting and rerouting calls Incremental migration, risk reduction, continuous delivery Legacy modernization, monolith-to-microservices transition\nCloud Integration Sidecar (Service Mesh) Infrastructure functionality deployed alongside services in containers Consistent cross-cutting capabilities, polyglot services Kubernetes environments, microservices architectures\nCloud Integration Event Sourcing Storing all state changes as a sequence of events Auditability, temporal queries, event replay capability Financial systems, domain-driven design, CQRS architectures\n6. Standard # What it actually is: Technical specifications everyone needs to follow to ensure things work together properly. Think of it as your technology rulebook.\nReal talk example: \u0026ldquo;All our web services must use REST APIs with OpenAPI specs, follow our naming conventions, and handle errors in a consistent way so other teams can integrate with them without wanting to pull their hair out.\u0026rdquo;\nWhen people misuse it: They create \u0026ldquo;standards\u0026rdquo; nobody follows, forget to document them, or make them so restrictive that teams can\u0026rsquo;t get their work done and end up asking for exceptions constantly.\n7. Guideline # What it actually is: Recommended (but optional) best practices. It\u0026rsquo;s your \u0026ldquo;you probably should, but you don\u0026rsquo;t have to\u0026rdquo; advice.\nReal talk example: \u0026ldquo;When you\u0026rsquo;re implementing caching, Redis is a good choice for sharing cache between services, while memory caching works fine for stuff that doesn\u0026rsquo;t need to be shared. But hey, use what makes sense for your situation.\u0026rdquo;\nWhen people misuse it: They treat guidelines as if they\u0026rsquo;re mandatory (making them de facto standards), or they\u0026rsquo;re so vague they provide no real guidance at all. \u0026ldquo;Make it secure\u0026rdquo; isn\u0026rsquo;t a guideline – it\u0026rsquo;s just stating the obvious.\n8. Architecture Decision Record (ADR) # Why We Need to Talk About ADRs\nLet\u0026rsquo;s face it – in the fast-paced world of technology, decisions get made and forgotten faster than you can say \u0026ldquo;agile sprint.\u0026rdquo; Without proper documentation, the reasoning behind critical architectural choices vanishes into thin air, leaving future teams scratching their heads and asking, \u0026ldquo;What were they thinking?, What was the long division?\u0026rdquo;\nAccording to a recent AWS blog post, development teams spend a staggering 20-30% of their time just coordinating with other teams. That\u0026rsquo;s time not spent building cool new features or fixing bugs. And when architectural decisions aren\u0026rsquo;t documented, teams waste even more time rehashing old debates or making inconsistent choices. YES AWS WRITE THINGS DOWN.\nThis is where Architecture Decision Records (ADRs) come in – they\u0026rsquo;re not just another document to create, but a lifeline for your future self and team. As the AWS article points out, effective ADRs can streamline decision-making processes, improve team collaboration, and significantly reduce architecture rework. Teams that implement ADRs properly can make decisions faster and more confidently, with one to three focused meetings rather than endless debates.\nWhat it actually is: Documentation of why you made a significant tech decision, what options you considered, and what tradeoffs you accepted. It\u0026rsquo;s how you avoid the dreaded \u0026ldquo;why on earth did we do it this way?\u0026rdquo; questions years later.\nReal talk example: \u0026ldquo;We decided to use GraphQL instead of REST for our data-heavy applications because it reduced network traffic by 40%, made frontend development faster, and gave us more flexibility. Yes, it\u0026rsquo;s more complex on the backend, but the tradeoffs were worth it for our use case.\u0026rdquo;\nADR (Architectural Decision Record) and TOGAF (The Open Group Architecture Framework) are linked in that ADRs are a valuable tool for documenting and managing architectural decisions, which is a core part of the TOGAF Architecture Development Method (ADM). TOGAF uses ADRs to record the history of decisions, ensuring transparency(key for high performing teams)and consistency within an enterprise architecture\nHow These Actually Work Together (When Used Properly) # Think of these concepts as different layers of decision-making that build on each other:\nStrategy and Principles are your foundation. They answer \u0026ldquo;where are we going?\u0026rdquo; and \u0026ldquo;what do we believe in?\u0026rdquo; Policies, Standards, and Patterns form your framework. They establish \u0026ldquo;what rules must we follow?\u0026rdquo; and \u0026ldquo;how should we approach common problems?\u0026rdquo; Procedures and Guidelines are your finishing touches. They specify \u0026ldquo;how exactly do we do this?\u0026rdquo; and \u0026ldquo;what\u0026rsquo;s worked well before?\u0026rdquo; ADRs document the journey, explaining why you made specific choices along the way. The Building Blocks vs. Patterns Confusion # One of the most head-scratching distinctions in architecture is between \u0026ldquo;building blocks\u0026rdquo; and \u0026ldquo;patterns.\u0026rdquo; Here\u0026rsquo;s what people get wrong:\nBuilding blocks are the LEGO pieces of your architecture – the components you use to build solutions:\nArchitectural Building Blocks (ABBs) are capabilities you need, like \u0026ldquo;Identity Management\u0026rdquo; Solution Building Blocks (SBBs) are specific products you\u0026rsquo;ve chosen, like \u0026ldquo;Okta\u0026rdquo; Patterns are the instruction manuals showing you clever ways to use those LEGO pieces. They don\u0026rsquo;t just tell you what to use – they explain how, when, and why to use it in a specific way.\nThink of it this way: building blocks are ingredients, while patterns are recipes. A building block just sits there waiting to be used. A pattern says, \u0026ldquo;Here\u0026rsquo;s a proven way to solve this problem using these building blocks, here\u0026rsquo;s when you should use this approach, and here are the tradeoffs you\u0026rsquo;ll make.\u0026rdquo;\nA Real Example That Ties Everything Together # Let me show you how this works in real life with a single example that connects all these concepts:\nStrategy: \u0026ldquo;We\u0026rsquo;re moving to the cloud over the next three years to be more agile and cut costs.\u0026rdquo; Principle: \u0026ldquo;Our systems should keep working even when parts fail. Period.\u0026rdquo; Pattern: \u0026ldquo;We\u0026rsquo;ll use the Circuit Breaker pattern so one failing service doesn\u0026rsquo;t bring down the whole system.\u0026rdquo; Standard: \u0026ldquo;Every service must have health checks that our monitoring can use to detect problems.\u0026rdquo; Building Block: \u0026ldquo;We need service mesh capability (ABB) and we\u0026rsquo;ll implement it with Istio (SBB).\u0026rdquo; Policy: \u0026ldquo;All production services must be available 99.9% of the time or heads will roll.\u0026rdquo; Procedure: \u0026ldquo;To provision cloud resources, you must use our infrastructure-as-code templates, get them reviewed, scan for security issues, get approval, and deploy through our pipeline.\u0026rdquo; Guideline: \u0026ldquo;Consider using feature flags so you can turn off non-critical features when the system is under stress.\u0026rdquo; ADR: \u0026ldquo;We chose Istio over Linkerd for our service mesh because it has more features and integrates better with our Kubernetes setup, even though it\u0026rsquo;s more complex.\u0026rdquo; See how each concept has its own distinct role? When we use these terms correctly, they actually help us communicate clearly instead of just sounding impressive in meetings.\nStraight Talk for New Architects # If you\u0026rsquo;re new to architecture, here\u0026rsquo;s some honest advice:\nStart with principles you can explain to anyone. If you can\u0026rsquo;t explain your principle to someone outside IT, it\u0026rsquo;s probably too complex or not actually a principle. Document your decisions before you forget why you made them. Creating ADRs isn\u0026rsquo;t busywork – it\u0026rsquo;s saving your future self (or your replacement) from massive headaches. The AWS blog recommends keeping ADR meetings short (30-45 minutes), focused on a single decision, and following a \u0026ldquo;readout\u0026rdquo; style where participants first read the document and provide written comments. Don\u0026rsquo;t reinvent the wheel – use patterns. Smart architects steal\u0026hellip; er, I mean \u0026ldquo;leverage existing knowledge.\u0026rdquo; Learn the common patterns in your domain. Build with LEGO, not cement. Design modular components that can be reassembled, not monolithic systems that can\u0026rsquo;t be changed without breaking everything. Make your standards easy to find and follow. If your standards are buried in a 200-page PDF nobody reads, they might as well not exist. As the AWS blog suggests, centralize your ADRs in a location accessible to all project members. The Bottom Line # Let\u0026rsquo;s be honest – half the battle in technology architecture is just clear communication. When we actually understand and correctly use terms like strategy, pattern, and standard, we stop talking past each other and start building better systems.\nThe next time someone throws around these terms in a meeting, maybe gently ask them to clarify what they mean. You might be surprised to discover they\u0026rsquo;re using a \u0026ldquo;principle\u0026rdquo; to describe what\u0026rsquo;s really just a preference, or calling something a \u0026ldquo;standard\u0026rdquo; when it\u0026rsquo;s actually more of a guideline.\nBy getting our terminology straight, we can focus on what really matters – creating technology that actually solves business problems instead of just generating impressive-sounding buzzwords.\n# # # # ","date":"10 May 2025","externalUrl":null,"permalink":"/posts/cut-through-the-architecture-buzzwords-what-these-terms-actually-mean/","section":"Posts","summary":"","title":"Cut Through the Architecture Buzzwords: What These Terms Actually Mean","type":"posts"},{"content":" Abstract # We investigate the widely held assumption that a refrigerator’s internal light turns off when the door is closed. Although this claim appears trivial, it presents an interesting test case for scientific reasoning, indirect observation, and hypothesis testing under constrained conditions. We designed and executed a series of experiments using mechanical switches, video capture, and light-sensing electronics to verify this hypothesis. Results from all three methods support the conclusion that the light does indeed extinguish upon door closure.\n1. Introduction # The question of whether the refrigerator light turns off when the door is closed has long intrigued curious minds. It is a quintessential example of a system that becomes unobservable once a specific action (door closure) occurs, raising both practical and philosophical questions. While this may seem mundane, it mirrors deeper scientific challenges: how can we infer the behaviour of systems when direct observation is impossible?\nThe objective of this investigation is to apply the scientific method to verify or refute the hypothesis: H₀ (Null Hypothesis): The refrigerator light remains on when the door is closed. H₁ (Alternative Hypothesis): The refrigerator light turns off when the door is closed.\n2. Methodology # 2.1 Visual Inspection of the Door Switch # Most household refrigerators are equipped with a mechanical switch or button along the inner door frame. When the door is open, this switch is released, allowing the internal light to activate. When the door closes, the switch is depressed, presumably turning off the light.\nProcedure: We manually pressed the switch with the door open and observed the behaviour of the internal light.\n2.2 Video Observation Method # A smartphone with video recording functionality was placed inside the refrigerator. The camera was positioned to capture the light directly. Recording began with the door open and continued during closure and for several seconds afterward.\nConsiderations:\nCamera night mode was disabled to avoid artificial brightness amplification. Stabilization and motion-detection auto-stop features were disabled. 2.3 Light Sensor with Microcontroller # A light-dependent resistor (LDR) was connected to an Arduino microcontroller to measure light intensity over time. Data were logged at 0.5-second intervals and plotted to observe transitions in light level.\nCircuit Setup:\nLDR in a voltage divider circuit. Analog pin measured voltage relative to light intensity. Data transmitted to serial monitor and logged. 3. Results # 3.1 Door Switch Test # Upon pressing the door switch manually, the internal light turned off consistently, supporting the hypothesis that the switch controls the light circuit.\n3.2 Video Recording # The video showed a distinct and immediate blackout at the moment of full door closure. There was no residual glow or flickering post-closure. Playback confirmed the light was extinguished when the door was shut.\n3.3 Sensor Data Logging # Light sensor readings dropped from ~800 lux (door open) to \u0026lt;5 lux (door closed), indicating near-total darkness within 1 second of closure. The graph exhibited a sharp transition with no indication of continued illumination.\n4. Discussion # All three independent methods converged on the same conclusion: the refrigerator light turns off when the door is closed. The mechanical door switch acts as a binary trigger for the light circuit, and there is no evidence of software-based delays or malfunctions in standard consumer refrigerators.\nFrom an epistemological perspective, this investigation demonstrates the use of indirect measurement and inference—a principle frequently employed in astrophysics, quantum mechanics, and systems engineering.\n5. Conclusion # This investigation confirmed the hypothesis that the refrigerator light turns off upon door closure. Through multiple methodologies—manual switch testing, internal video capture, and light sensor instrumentation—we observed consistent results validating the off-state of the light.\n6. Why I wrote this # I wrote this for Shiela, but I also wrote it to all the auditors that are trying to follow Auditing Standard n.5 from the PCAOB. Having being an auditor myself, I understand what you going through! Don\u0026rsquo;t take it personal ;-)\n","date":"25 March 2025","externalUrl":null,"permalink":"/posts/does-the-refrigerator-light-turn-off-when-the-door-closes-a-scientific-study/","section":"Posts","summary":"","title":"Does the Refrigerator Light Turn Off When the Door Closes? A Scientific Study","type":"posts"},{"content":" Data Localisation: A Privacy Engineer\u0026rsquo;s Nightmare # Right, let\u0026rsquo;s talk about data. Not just any data, but that juicy, personal data that everyone seems to want a piece of. Governments want to control it, companies want to use it, and privacy engineers? Well, we\u0026rsquo;re stuck in the middle, trying to make sure everything\u0026rsquo;s secure and compliant while not completely ruining the user experience. Stuck between, laws ⚖️, lawyers interpresation of the law and the reality of the laws of physics!\nIn reality It’s a tangled mess of legal complexity, technical inefficiencies, and unintended security risks. As privacy engineers, we find ourselves juggling compliance, security, and business needs, all while trying not to make the user experience unbearable.\nThis post dives into the real challenges of data localisation, residency, and sovereignty, unpacking how CDNs, hyperscale cloud computing, geopolitics, and privacy-enhancing technologies (PETs) all play a role. We’ll explore why data access matters as much as data storage, how politics and national pride shape data laws, and why blindly enforcing localisation might actually weaken security rather than strengthen it. Most importantly, we’ll discuss practical solutions—from encryption and tokenization to standard contractual clauses and federated identity systems—that can help privacy engineers navigate this chaos while keeping data safe and compliant.\nWhat\u0026rsquo;s the Diff? Localisation vs. Residency vs. Sovereignty # First, let\u0026rsquo;s get our terms straight, because these words are often thrown around like like popcorn at a movie theater 🍿, with everyone vaguely understanding what\u0026rsquo;s going on but not really paying attention to the details.\nData Localisation: This is where the data must be stored and processed within a specific country\u0026rsquo;s borders. Think of it as building a digital fence around the data, saying, \u0026ldquo;You shall not pass!\u0026rdquo;. Data Residency: Similar to localisation, but sometimes a bit more flexible. It means data should be stored within a country, but processing might happen elsewhere under certain conditions. It\u0026rsquo;s like saying, \u0026ldquo;You can visit other countries, data, but your primary residence is here.\u0026rdquo; Data Sovereignty: This is the big one. It\u0026rsquo;s about a nation\u0026rsquo;s right to govern the data of its citizens and inhabitants, no matter where it\u0026rsquo;s stored. It’s the digital equivalent of national pride and the right to make your own rules. InCountry has a good overview of most countries with Data Sovereignty law\u0026hellip;.. many. Now I am no lawyer, but although some countries might have Data localization laws, it is important to look at the details as they differ and we can not polarize this area too quickly. For example, the French🥐 Health Data Host (HDS) certification framework mandates that any service provider hosting personal health data must store this data exclusively within the European Economic Area (EEA). This requirement applies to both the primary host and any subcontractors involved in the storage of such data. Additionally, if the service involves remote access from outside the EEA, it must be based on an adequacy decision (lastest listof adequate countries) by the European Commission or other appropriate safeguards. The host is also obligated to inform clients about the data storage locations and disclose any non-EEA regulations that might require unauthorized access to the personal health data.\nIn addition, if this is not possible, for example how many have outsources to india IT operations? Well for this we have the following tools 🔨 to help with this:\n**Standard Contractual Clauses (SCCs):**The most common method for EEA-India data transfers and requires your Indian service provider to contractually commit to GDPR-level protections **Binding Corporate Rules (BCRs):**Used by multinational corporations for intra-group data transfers and requires approval from EU data protection authorities. There are several derogation (Article 49 of GDPR) so watch out for this one. **Data Localization Approach:**Instead of transferring data to India, keep it in the EEA and allow controlled access from India (e.g., via secure VPNs or cloud-based remote work environments). Long story short, read the long text and don\u0026rsquo;t stop at the headline. I am sure we have all been in a meeting discussing if we can do something or not and there is always someone that says\u0026hellip; not allowed🚫, the data can not leave the country! Well there are save ways\u0026hellip; you just need to read the law\u0026hellip;yes privacy engineers\u0026hellip; read the law!\nThe Hyperscale Headache: CDNs, Resiliency, and the Need for Speed # Now, here\u0026rsquo;s where things get tricky. We live in a world of hyperscale computing, where data is replicated across the globe to provide resiliency and speedy access (see the image of this post).\nContent Delivery Networks (CDNs): These are essential for delivering cat videos and important information quickly, by caching data on servers closer to the user. A Web Application Firewall (WAF) : This is a security layer designed to filter, monitor, and block malicious traffic targeting web applications. Cloud providers typically distribute WAFs across their global infrastructure, integrating them with Content Delivery Networks (CDNs) to enhance both security and performance. A key challenge with decentralized security enforcement is inconsistency in policy application. If IP blocklists and security rules must be maintained separately across multiple regions (e.g., 35+ locations), it creates operational complexity, increases costs, and leads to gaps in protection. A centrally managed, globally distributed WAF ensures uniform security policies, reducing administrative overhead and enhancing bot protection, threat mitigation, and customer experience. By automating policy enforcement across regions via cloud-native WAF services, organizations achieve stronger, more consistent security while maintaining agility and cost-efficiency. Disaster Recovery: Replicating data across multiple regions ensures that if one data centre goes poof, everything keeps running. Phil Venables, in his blog post, \u0026ldquo;Stressed Testing: Practical Operational Resilience\u0026rdquo;, leaves clear that resiliciency is about a business service oriented view of resilience - as opposed to a business function (department / process) or IT-centric view of resilience. But, how do you reconcile this need for global distribution with data localisation laws? It\u0026rsquo;s like trying to fit a square🟩 peg in a round 🔴 hole, or trying to explain to your grandma what a blockchain is.\nGeopolitics and Data: A Thorny Relationship # Ah, politics. Never far from anything complex. National politics and changing international relations dramatically influence data strategies. Data is the new oil🛢️?\nWhile **Nationalism might be a tendency ,**where countries might want their citizens\u0026rsquo; data stored locally out of a sense of national pride or a desire to keep an eye on things, sometimes there are Economic Incentivesthat drive the creation of data centres which could mean jobs and investment. Some countries use localisation laws to attract these, hoping to become the next Silicon Valley, but the counter is true. A studyof six developing countries and the EU-28 found that data localisation regulations could reduce GDP by up to 1.7 %, investments up to 4.2 %, and exports by 1.7 %.\nIf that was not enough,Weaponization🔫of privacy is a another byproduct of geopolitical tensions where data can become a bargaining chip. Restricting data flows can be a way to exert pressure on other nations.\nFinally, uncertainty effect**,**is a reality, with changing political landscapes, trade wars looming, international agreements on data flows can be thrown into chaos. Remember the whole \u0026ldquo;safe harbour\u0026rdquo; agreement debacle?. NOYBreleased an interesting articile, on the challenges of the US cloud providers. Apple 🍎 to open up access to users data etc. Its getting interesting, and non of this help the people on the ground with their privacy in my view.\nThe Illusion of Security: Why Localisation Isn\u0026rsquo;t a Silver Bullet # Here\u0026rsquo;s a harsh truth: data localisation doesn\u0026rsquo;t automatically make data more secure. Think of it like this: putting your valuables in a safe doesn\u0026rsquo;t matter if the safe is made of cardboard and the key is under the doormat. Are you really going to run this bettter than the CSP? are you really going to be able to drive a consistant pattern in 35 locations, with 35 separate teams (remeber this is where the data is accessed from)? Really. Yes you could have a bunch or smart folks in your engineering team and automate it, but automations break, the api\u0026rsquo;s they call change and it all needs to be maintained. Be realistic, it is just not a sustainbility security strategy. Maybe it gives you a warm feeling, but business does not run on warm feelings!\nToday\u0026rsquo;s Cloud Service Providers offer dynamic security practices at scale that dramatically improve every customer’s security posture, given that best-of-breed security is mandatory for a successful hyperscale CSP and security must be fully integrated into the design, development, and operations of hyperscale cloud services. Note there is still a lot in the shared responsibility model that the customer of the CSP needs to do to ensure they keep there consumers data secure and private, but you want to leverage as much as you can of the heavy lifting.\nHere are some reasons why data localization, sometimes it can make things worse:\nConcentrated Risk: Storing all data in one location makes it a bigger target for cyberattacks. Smaller Providers: Local providers might not have the same security expertise or resources as hyperscale cloud providers. Insider Threats: The physical location of data does not significantly impact the core security objectives of confidentiality, integrity, and availability. These are just some, I have used several examples in this post already of why this is just not feasible or sustainable. AWS have a great blog post on this topic here.\nAccessibility Matters: The GDPR Perspective # But here\u0026rsquo;s the rub: even if you do manage to store your data within a specific country, you\u0026rsquo;re not necessarily in the clear. GDPR, for example, focuses not just on where the data is physically located but where it is accessible from. Article 44 of the GDPR prohibits the transfer of personal data to third countries unless specific conditions are met, ensuring that the level of protection of individuals guaranteed by the GDPR is not undermined. Additionally, Article 46 outlines appropriate safeguards for such transfers, including standard data protection clauses or binding corporate rules. Therefore, even if data is physically stored within the EEA for example, accessing it from a non-EEA country like India (most outsourcing) is subject to GDPR\u0026rsquo;s data transfer provisions, necessitating appropriate safeguards to protect the data during and after the transfer.\nThink about it:\nOutsourced Operations: How many companies have outsourced their operations to other countries? If your system is in the UK but the support team is in India, is the data really in the UK? Global Access: If employees or contractors in other countries can access the data remotely, does localisation even matter? Mutual Legal Assistance Treaties (MLATs): These agreements allow governments to request data from companies even if it\u0026rsquo;s stored in another country. Predictability, Manageability, Disassociability, and the Multi-IDP Mess # Privacy isn\u0026rsquo;t just about security; it\u0026rsquo;s also about control. NIST in its PaperNISTIR 8062 \u0026ldquo;An Introduction to Privacy Engineering and Risk Management in Federal Systems\u0026rdquo; call out the following Privacy Engineering Objectives - to help system engineers focus on the types of capabilities a system needs in order to demonstrate how the privacy policies and system privacy requirements have been truley implemented.\nPredictability: ensures that individuals and system operators have a reliable understanding of how personally identifiable information (PII) is handled, minimizing surprises and maintaining trust through transparency, accountability, and consistent privacy practices. Manageability: is the ability to administer, update, and enforce privacy controls over personal data, ensuring accuracy, minimization, and compliance while enabling appropriate oversight and governance of information handling. For me this is one of the key elements to consider. If something is hard to manage, it is hard to secure and then things just are not going to end well. I could could many laws, like Gall Law, or Le Chatelier’s Principle in systems theory or even the Second Law of Thermodynamics, which while a physical law,it metaphorically applies to complex systems where as complexity increases, disorder (entropy) also tends to increase unless actively managed. Long a short of it is that when a system becomes more intricate, unforeseen disruptions and inefficiencies increase. Fact. Disassociability: refers to a key aspect of privacy-preserving systems, ensuring that a person\u0026rsquo;s identity or activities remain hidden from unnecessary exposure. Unlike confidentiality, which focuses on preventing unauthorized access, disassociability acknowledges that privacy risks can arise even within trusted environments. It enhances privacy by prompting system designers and engineers to identify and eliminate unnecessary points of exposure, ensuring that only essential data is linked to individuals. This principle closely aligns with data minimization, as it encourages reducing the collection and retention of personally identifiable information whenever possible. Now lets take the example of a company trying to run a IDP for it consumer and customers across 35 countries. Imagine you\u0026rsquo;re the privacy engineer trying to uphold these principles in this world where multiple Identity Providers (IDPs), each with its own rules and regulations, spread across many countries. It\u0026rsquo;s a nightmare! This will lead to inter alia:\nInconsistent Policies: Each IDP might have different privacy policies, making it hard to ensure consistent protection. Federation Headaches: Federating these IDPs across multiple countries? You\u0026rsquo;re just asking for trouble. Different legal standards for law-enforcement access, data retention, data security, censorship, and other data-related requirements can put a firm into a legal catch-22. Lack of Visibility: It\u0026rsquo;s hard to keep track of where data is, who has access, and what they\u0026rsquo;re doing with it. Increased Strain on Technology: Many institutions have difficulty identifying all systems that store sensitive information and deploying controls for them. Privacy Theatre or Genuine Concern? # So, is all this data localisation just \u0026ldquo;privacy theatre\u0026rdquo;? Are we weaponizing people\u0026rsquo;s rights for other reasons that care very little about this fundamental right? It\u0026rsquo;s a valid question.\nEconomic Protectionism: Could data localisation be a way for countries to protect their local industries and create trade barriers? Government Surveillance: Does keeping data within borders make it easier for governments to spy on their own citizens? Geopolitical Power Plays: Is data sovereignty just a new form of nationalism, a way for countries to assert their power in the digital world? PETs to the Rescue? Privacy-Enhancing Technologies to the Rescue # So, is there any hope? Well, maybe. Privacy-Enhancing Technologies (PETs) offer a glimmer of light in this otherwise gloomy landscape.\nHere are some PETs that might be useful to consider:\nData Minimisation: This is the most basic, micky mouse one. \u0026ldquo;Can we achieve the same with less privacy-invasive methods, or while processing less personal data?\u0026rdquo; Only collect and retain what you absolutely need. If you don\u0026rsquo;t need it, don\u0026rsquo;t store it. - This is the cheapest and best PET of them all, but requires people changing there ways\u0026hellip;. hard is it not? Encryption: Encrypting data with keys that only you control means you can store it anywhere, and it\u0026rsquo;s useless to anyone without the key. This involves Bring Your Own Key\u0026quot; (BYOK) or commonly referred to as Customer-Managed Keys (CMK) or Customer-Supplied Encryption Keys and rendering data useless if you do not have the keys so you can host anywhere. All CSP have flavours of it. AWSwith Customer-Managed Keys (CMK) in AWS KMS, Microsoft Azurecalls themCustomer Managed Keys in Azure Key Vault or **Google Cloud Platform (GCP)**with Customer-Supplied Encryption Keys (CSEK). Tokenization: Replacing sensitive data with non-sensitive tokens allows you to process data without exposing the real stuff. Data anonymisation the encryption of data is considered an anonymization technique. Homomorphic Encryption: Performing computations on encrypted data without decrypting it. If I were you, I would focus on the simple solution to complex problems first. The Way Forward: Pragmatism, Collaboration, and a Bit of Luck # Navigating the world of data localisation is a challenge, but not an insurmountable one. Here\u0026rsquo;s my advice for privacy engineers:\nEmbrace Pragmatism: You can\u0026rsquo;t fight every battle. Focus on the most critical data and the most stringent regulations. Read the Law: do not stop at the headline. The law many a times is flexible given controls are in place. Advocate for Standards: Push for international standards and agreements on data privacy and security. PETs: These technologies are the future of privacy but doe not start with the fancy ones first. Start with the simple ones! Collaborate: Work with legal, security, and business teams to find solutions that work for everyone. Keep talking! Keep Learning: The landscape is constantly changing. Stay informed, stay agile, and try to maintain a sense of humour. Final Thoughts # Data localisation, residency, and sovereignty are complex issues with no easy answers. But by understanding the challenges, embracing new technologies, and working together, we can build a future where data is both secure and accessible, where innovation thrives, and where privacy is respected.\n","date":"9 February 2025","externalUrl":null,"permalink":"/posts/why-data-localisation-might-be-hurting-your-privacy-a-privacy-engineers-perspective/","section":"Posts","summary":"","title":"Why Data Localisation Might Be Hurting Your Privacy - A Privacy Engineers perspective","type":"posts"},{"content":"Protecting Personal information is every one’s job, and we do it to ensure we respect the privacy of individuals and grain the necessary trust to maintain a shared value relationship with those individuals. This is the Why we do it. What is good for the induvial is good for the business.\nHence GDPR calls this out in in article 25:\nPrivacy by Design means that data protection must be an integral part of the design and operationof any system, service, or product that processes personal data. Organizations should implement technical and organizational measures to ensure privacy is embedded in all stages of data processing. It is not just about securing data but also about minimizing the amount of personal data collected, limiting its use, ensuring accuracy, and deleting it when no longer needed. For the purposes of simplicity, we will refer to the main target of privacy to be the Consumer(b2c) and Customer (b2b) given this is where the highest risk is, although we recognise that this includes all personal data an organisation needs to process for legitimate purposes, or has consent to process e.g. Employee Data (b2e).\nThis blog post outlines the How (we make it part of the Operation, see definition)and What and When we will execute on the different technology elements that are necessary to establish a privacy by design environment. Sequencing and alignment with broader corporate initiatives is paramount and we can not think of this as purely a compliance requirement although compliance is the path to ensuring digital trust.\nApproach to x by design # Anything by design embeds functional and non-functional requirements into the products, processes and technology of the business flow of work. In this manner we are shifting left requirements and solving it where it the problem or challenge is created or more important, where the context is. A great quote I found about vulnerability management bring this to life.\n💡Vulnerability Management is not about finding issues - It\u0026rsquo;s about fixing them in context!This approach will minimize building in quality after the fact into a process or increasing oversight process or tools to compensate for broken process or technology. This roadmap focuses on addressing the root cause.\nSolving this addresses the most important challenge in distributed organizations, and that is the one of accountability. Accountability for Privacy, in this case needs to primarily land with the business process and technology that manages the customer and consumer data. Replace the word privacy for security and it also work. Test it.\nThe first key differentiator is to distinguish two separate products, whilst related, the order and sequence of design and operations is fundamental to be effective and efficient. They address a common concern (why), but focus on the how and what needs to be done in fundamentally different way and target different secondary personas within the organization.\nNote this pattern can be seen in many other domains, like information Security, Compliance, financial compliance etc. Think of central control functions in general or anything we setup a central function for to get other to do things.\nDifferentiating Internal Privacy Products and Business-Embedded Privacy Product Features # In the context of managing privacy within an organization, it\u0026rsquo;s essential to distinguish between two categories of privacy products and features:\nInternal Privacy Products for Privacy or Privacy for Privacy. (remember this also works for Security for Security ;-)) Business-Embedded Privacy(or security) Products and Features While these categories are interdependent, their roles and functionalities differ significantly. Understanding and communicating these distinctions helps ensure clarity in implementation, accountability, and governance. It helps be explicit so there are NO turf wars.🥷\nThis distinction also helps provide clarity for the Architecture domain and hence ensuring we have the right architecture supporting the initiatives.\nInternal Privacy Products for Privacy # Definition # Internal privacy products are tools, platforms, or processes designed to provide the privacy team with oversight, governance, and control over privacy compliance across the organization. These products monitor, validate, and assess the effectiveness of privacy measures within the business, ensuring that privacy risks are managed in line with internal policies and regulatory requirements.\nKey Differentiation: # Internal privacy products should never have an operational nature or interfere with business processes and customer-facing interactions. They are not meant to replace or replicate any operational activities already conducted within the business. Instead, internal privacy products are designed to work in the background, feeding off the signals, logs, and data points provided by business-embedded privacy features.\nWhilst this is the key differentiation, it is paramount that the privacy requirements are fed into the design and operation of the business process to augment it and enhance it as requirements evolve. The difference is how we do things. Do not do it for them, but help them (the business) do it themselves!\nExample: Incident Management Considerations: # Privacy incident management is not a standalone process operated solely by the privacy team. Rather, it should be a subrogated process that leverages the existing incident management frameworks already established within the business. No new incident management process should be created specifically for privacy incidents or additional reporting systems and portals. Instead, these incidents should be managed within existing channels (e.g., IT or customer support systems), escalating to the privacy team only when necessary BUT in a programmatic way, driving out subjectivity. This ensures that incidents are handled efficiently and, in a manner, consistent with other types of incidents, while still allowing the privacy team to intervene in complex or high-risk cases.\nA good example of this would be to eliminate any channel with the customer that might lead to subjectivity and try be as explicit as possible. e.g. unstructured email channels here the customer might need to go back a forth n number of times to define the ask given the options where not explicit in the first place. This drives consistency and consistency drives digital trust. See Robert Cialdini six principles of influence to learn more and in particular the Principle of Commitment and Behavorial Consistency\nMoreover, most privacy-related requests and incidents should be addressed through self-service platforms and tools embedded into business processes. This reduces the need for separate tools hosted by the privacy team, ensuring that privacy requests and incident handling are seamlessly integrated into the business\u0026rsquo;s natural workflows.\nMaximizing the self-service approach is key for multiple reasons:\nScale: It permits the process to scale. At potentially Millions of customer interactions this is a requirement. Declarative: makes the process explicit and declarative, eliminating subjectivity in the degree possible that can creep in when people subjectivity is applied. Consistency: Customers expect a consistent experience in several domains, e.g. Identity registration and login. Privacy is just another one of these requirements. Characteristics: # Oversight \u0026amp; Monitoring: Enable the privacy team to continuously monitor and assess privacy risks, data flows, and compliance status, using data collected by business-embedded features. Governance \u0026amp; Reporting: Facilitate reporting mechanisms, control checks, and compliance documentation for internal and external stakeholders. Independence from Business Operations: Operate independently of business processes, drawing information from business-embedded privacy features, and ensuring no operational activities or customer interactions take place within these tools. Minimal Intrusion: Avoid disrupting the natural flow of business operations, intervening only when necessary (e.g., in the case of privacy breaches or non-compliance) and escalated through established channels. Examples: # Privacy Incident Management Integration: Integrated as a sub-process within the broader incident management system, where privacy incidents are flagged and automatically escalated to the privacy team when necessary. For instance, data breaches reported through a central IT system will notify the privacy team for assessment and response, but initial incident handling occurs through the existing IT channels. Data Inventory \u0026amp; Mapping processes: Captures data flows, processing activities, and data sharing across the organization. The privacy team uses this tool to understand where personal data is stored, used, and shared, without affecting customer-facing systems or business workflows. NOTE Ideally this would be incorporated into the Customer Data processing domain as standard documentation and not need to be a privacy function Automated Compliance Assessment Tools: Periodically checks compliance against regulatory requirements (e.g., GDPR, CCPA) and internal policies by analysing data fed from business processes, without requiring ongoing manual input from business units. These NEED to be aligned with the broader compliance Tools and platforms in the GRC functional domain. Remember tomorrow we will have AI compliance teams spin up, then Xyz Regulation Team etc etc. 2. Business-Embedded Privacy Features # Definition: # Business-embedded privacy features are the privacy-enhancing measures, controls, and functionalities integrated directly into business platforms, systems, or processes. so basically as the GDPR definition states it , be an integral part of the design and operationof any system, service, or product that processes personal data. These features ensure that privacy considerations are embedded into the design and operation of products and services, minimizing risks at the source.\nKey Differentiation: # Business-embedded privacy features must reside within the existing business processes and customer channels. This includes interfaces like websites, customer chatbots, mobile apps, customer care, case management processes, and customer communications. They are responsible for ensuring that privacy is preserved at the point of interaction, enabling compliance without requiring direct oversight from internal privacy products during real-time operations because it is already embedded into the process.\nA critical aspect is that the management of customer privacy requests (such as data subject access requests or consent management) and privacy-related incidents should be handled through self-service platforms and tools directly embedded into business processes, rather than separate tools hosted by the federated teams. This approach ensures that the business processes remain the primary point of interaction for customers, with privacy considerations built into the channels that customers are already familiar with.\nCharacteristics: # Integrated Design: Incorporated into the platforms or processes that handle personal data, ensuring that privacy-by-design principles are followed at every customer touchpoint. Proactive Risk Mitigation: Address privacy risks at the point of data collection, use, or sharing, preventing issues before they escalate and ensuring customer interactions are privacy compliant. Seamless Business Operation: Designed to work within the business processes without additional intervention or oversight Interoperability: Provide necessary data and signals to internal privacy products for oversight and monitoring purposes, but never assume a governance role. Examples: # Automated Data Minimization: A feature in customer-facing systems, such as websites or mobile apps, that only collects necessary data fields for the intended purpose, minimizing the collection of personally identifiable information (PII) in real time. This would be a data domain feature and not a specific capability we would build out by a central privacy programme Consent and Preference Management Platform: Embedded in customer-facing platforms, allowing users to provide or withdraw consent for different types of data processing activities. The system then signals the consent status to internal privacy products, enabling compliance tracking without interfering in customer interactions Self-Service Privacy Requests: A mechanism that allows customers to directly submit privacy-related requests (e.g., data deletion, access requests) through existing interfaces like websites or mobile apps. This avoids the need for the privacy team to host separate tools, as the business processes remain the primary point of contact or more important to flip between teams. Privacy teams will be activated declaratively when a new pattern arises, and this pattern will be used to enhance the self-service flow. Interaction Between the Two Categories # While business-embedded privacy features are designed to be a part of the natural workflow of the business, internal privacy products provide the mechanisms for oversight and assurance. Internal privacy products rely on signals, logs, and reports from the business-embedded privacy features to function effectively. This relationship allows the privacy team to maintain governance without disrupting business operations, ensuring privacy controls are functioning as intended and compliance is maintained.\nInternal privacy products serve as the second line of defence, supporting governance without encroaching on business operations or directly interacting with customers. This ensures that privacy management is robust yet unobtrusive, maintaining the integrity of both business functions and customer experiences.\nThe approach is to improve the “first line of defence” to minimize the second line. See Three Lines of Defense 2.0? for more insights on how investment should also reflect this line of defence strategy. if 99% of your investment is going to second line then do not expect a by design outcome!\nThe above diagram shows how you need to play wiht the natuarl team tension that can arise while you move the dial to the right or left of this specttrum. What is right in one moment is not for another, but what is clear is if we shift accountability to the right to second line functions this will spell that we have not done enough to build the control requirement in from the get go in the operations and hence are ineffective. Giving up this power to the centrals teams does not come naturally and requires strong competency based leadership that truly understand these domains. In particular for the privacy domain Mitre articulated this clearly in there Privacy Engineering Framework and Lifecycle Adaptation Guide already in 2019!\nArticulating the Relationship # Business-embedded privacy features handle all operational aspects of privacy within the business processes and customer channels. They act as the first line of defence, ensuring privacy risks are managed at the source through direct engagement with customers or consumers. Internal privacy products, on the other hand, provide the second line of defence—focused solely on oversight and governance, never assuming an operational role or customer-facing responsibilities.\nThis layered approach allows the privacy team to support business operations in a manner that minimizes direct involvement in day-to-day activities, enabling proactive and efficient privacy management while preserving the efficiency and flow of business processes.\nThis articulation, along with examples, should provide a clear distinction between the two types of privacy tools, emphasizing their distinct roles and operational boundaries within the organization.\nConclusion # Finding the right mix a the right time in the organization is not easy hence agreeing the WHY is paramount with the different stakeholders.\nPrivacy by Design is complex to do it right but it is a people challenge and not a technology one.\nThe views, thoughts, and opinions expressed in this blog are solely my own and do not necessarily reflect the views, positions, or policies of my employer or any other organization I may be affiliated with. The information provided on this blog is for general informational purposes only and should not be considered as legal, financial, or professional advice\n","date":"12 October 2024","externalUrl":null,"permalink":"/posts/privacy-by-design-distinguishing-domains-for-central-teams/","section":"Posts","summary":"","title":"Privacy by Design: Distinguishing Domains for Central Teams","type":"posts"},{"content":"In large enterprises, centralized control functions like legal counsel, ethics, cybersecurity, and compliance departments are created with a clear purpose: to support the business in achieving its objectives while ensuring adherence to regulations and internal policies.\nAs these teams form and develop overtime they will present what we will call collective behavioral patterns that if we are not aware can lead suboptimal interactions with the broader collective. The one they need to embedded in, or form part of. Note this is not done consciensly normally, but group think and other force are natuarally at play in addition so simple human natuare and the basic need of self preservation.\nThese behaviors develop rituals, processes, and even belief systems that prioritize an inward looking prioritization over business outcomes or common higher order goals, leading to what sociologist René Girard would call a \u0026ldquo;mimetic society.\u0026rdquo;. Luca Dellanna has a good summary of the consequences here in his blog poston the topic.\nAnother force at play is Conway’s Law, which posits that organizations design systems that mirror their internal communication structures. When applied to central control functions, this means that as teams grow, they naturally create work that reflects their internal goals, rather than the needs of the business. These teams start generating activities that, while justifying their existence, do not necessarily align with or advance the company\u0026rsquo;s broader objectives. More importantly their natural center of gravity becomes themselves versus the business they are supporting, loosing context progressively as time goes by.\nYou can start to see that these concepts and forces converge to create collective behavivour, un intended in the greatest degree I would like to believe, yet impacting the large organization they form part of.\nThe Pitfalls of Inward Focus and Team Self-Justification # Central control functions—whether cybersecurity, compliance, privacy or legal—are designed to help manage risks and ensure accountability. However, as these teams expand, they can become more focused on creating work that at first sight would be justified, the mere non embedded nature of their teams, tools and processes have them focus on internal challenges of scale, rather than collaborating with other their stakeholders and driving value for the business.\nIn the absence of clear feedback loops, centralized teams can start developing processes that serve their own internal needs, rather than solving the challenges faced by the business. This is an example of Conway’s Law in action: the structure and communication patterns of these teams shape the systems and processes they create. Rather than being built to streamline operations or mitigate real risks, many processes become rituals that reinforce the internal hierarchy and justify the team’s continued growth. Lets face it these areas have big sticks 🏑 and they can pull on like, this is the law, even if a more accurate definition would be, this is how we interpret the law. Who are we to tell a Cyber Expert that there is more context to consider and that a situation might be nuanced. The non-believers who point this out can even be subject to an inquisition for their heresy as Phil Venables points out in his blog post Ceremonial Security and Cargo Cults\nFor example, a compliance department might develop increasingly complex procedures that ensure every box is ticked—regardless of whether this actually improves the organization’s compliance posture or business outcomes. In such environments, attempts to improve or simplify these processes are often met with resistance. Criticism of existing practices is seen as a threat to the team’s role, and those questioning the processes are viewed as challenging the very existence of the department. So it is not really safe to critique them as they start on a control plane in the organization that gives them power that simply get people to do things without justifying themselve, aluding to competency in their domain.\nThe Influence of Conway’s Law on Control Functions # Conway’s Law suggests that organizations will produce designs and processes that reflect their internal structures. In the case of central control functions, this can lead to the creation of work that serves the team’s need to maintain relevance and justify its size, rather than benefiting the business.\nAs teams grow, they generate more internal work—developing new processes, requiring more approvals, and creating more oversight mechanisms. This expansion often reflects the team’s internal communication structures rather than the actual needs of the business. What was once a lean, supportive function can balloon into a cumbersome bureaucracy that demands more and more resources while contributing less to the organization’s strategic goals.\nFor example, cybersecurity teams may introduce more and more layers of process to mitigate risk. However, these additional layers often slow down product development and innovation without significantly improving the organization’s security posture. This work is generated not because the business needs it, but because the team needs to demonstrate its importance. The result is a feedback loop where the team’s size and complexity grow in response to the very systems it has created. Basically building quality in after the fact, rather then in the the process. As Jonathan Smart put it, Quality is built in rather than inspected in later from his book Sooner Safer Happier: Antipatterns and Patterns for Business Agility. Its this \u0026ldquo;inspected\u0026rdquo; later piece we have to get right!\nTrust, Decentralization, and Encouraging the Right Behaviours # To counteract the self-perpetuating work generated by centralized teams, it’s essential to design tools and processes that promote the right behaviours and outcomes. This involves moving away from an inward focus and trusting decentralized teams to make decisions within well-defined parameters.\nAs Matthew Barzun explores in \u0026ldquo;The Power of Giving Away Power,\u0026rdquo; centralized functions must be willing to trust decentralized teams, allowing them to take ownership of their areas while operating within clear guidelines. This approach requires shifting from a command-and-control model to a participatory governance structure, where decentralized teams help shape the goals and systems they will be held accountable for. By involving these teams in the decision-making process, central functions can focus on enabling success, rather than creating unnecessary work.\nWhen centralized teams give decentralized teams more autonomy, they reduce the need for complex, self-justifying processes. Instead, teams can focus on embedding compliance and governance into everyday operations, ensuring that accountability is achieved without creating unnecessary overhead. See my blog series that starts with Rethinking the Three Lines of Defence: Putting Customers at the Core of Compliance on how to shift everything left, more it in to the flow of work that support the business value stream. You move to the work not the work to you. This is applicable for any support function. Test it. We will look more at this in the following section.\nEmbedding Accountability into the Flow of Work # A critical way to break the cycle of self-generated work is by embedding accountability directly into the flow of work, ensuring that systems and processes align with real business needs. Instead of creating compliance systems that function independently of daily operations, businesses can integrate these systems into existing workflows.\nFor example, Governance, Risk, and Compliance (GRC) functions need oversight tools, but those tools should complement the work of decentralized teams, rather than adding unnecessary complexity. By embedding compliance into everyday processes, organizations can minimize the need for additional reviews and approvals, ensuring that compliance is managed efficiently at the source. Get controls right in the first line.\nWhen compliance systems are integrated into the flow of work, central functions can avoid creating work that exists purely to sustain their own operations. Instead, they focus on facilitating real outcomes for the business, ensuring that accountability is built into the business itself.\nVERY important this is not a binary. The right level of Centralization needs to be found. This goldilocks space is not static. For example when creating a new function you might need to over scale the central accountability as the the federated teams are trained, provided the right tools, guidance is clear and explicit. As Luca Dellanna put it be super-clear: not just enough so that you can be understood but clear enough so that you cannot be misunderstood\n💡be super-clear: not just enough so that you can be understood but clear enough so that you cannot be misunderstood### Example: Privacy by Design\nAs an example, the concept of Privacy by Design demonstrates how central control functions can shift from generating internal work to enabling decentralized accountability. Rather than treating privacy as an after-the-fact compliance exercise, it should be an integral part of how the business operates, with tools embedded directly into customer-facing systems.\nBy design means embedding so it just happens as business as usually. This is not easy and needs the support of Experts in these compliance domains NOT to take on the accountability of those that need to do the work to keep the customer data safe but to fix and enhance those processes do the central functions oversight can be less everyday. This is the OKR!\n💡OKR: how much time do central teams spend in a week listening to learn (not fix or win), the business processes they are suppose to improve versus internal team discussion on how to scale a process or even better listening to the phase \u0026ldquo;they just do not get it!, why do they just not do what we tell them? We are the experts after all are we not?You can get a deeper dive on how this subject can influece privacy by design as an example in this blog post.\nThe key thing to remember this is always the same pattern, we need to distinguish two groups of personas X for X or X for the business or operations, or products for central functions versus products for the business. e.g GRC for GRC and GRC for the business are very different, yet related. More in the following section.\nInternal vs. Business-Embedded Tools: Striking the Right Balance # To avoid the pitfalls it’s important to differentiate between internal oversight tools and business-embedded features. Internal tools are necessary for governance, but they should operate in the background, supporting rather than complicating business processes.\nBusiness-embedded tools, on the other hand, should be integrated directly into the day-to-day processes of the organization. Features like automated data minimization or real-time compliance checks should operate within customer-facing systems, ensuring that compliance is managed where it matters most. This reduces the need for ongoing intervention by centralized teams and ensures that compliance is handled effectively without generating additional layers of work.\nBy balancing these two approaches, organizations can create systems that support the business without falling into the trap of generating unnecessary work to sustain centralized functions.\n💡OKR: as in previuos blogs a simple measure is to review you investment bugdet and see how much you are investing checking broken process, versus fixing it. In spanishing there is a saying, \u0026ldquo;Stop weighing the pig and instead feed it please!\u0026rdquo;### Participatory Governance: Involving Decentralized Teams in the Process\nOne way to ensure that central control functions avoid generating unnecessary work is to adopt a participatory governance model. This approach involves decentralized teams in the design and implementation of governance frameworks, ensuring that the processes reflect the real challenges they face in their day-to-day work. See more on in deciding how to decide blog post.\nBy involving the people who understand the realities on the ground, central teams can create more practical and effective solutions. This helps prevent the creation of work that exists purely to serve internal needs, and instead ensures that governance frameworks align with the business’s goals. It also fosters greater trust between centralized and decentralized teams, allowing for smoother operations and more efficient compliance.\nShifting Toward Real Accountability and Reducing Rituals # Improving the efficiency of central control functions requires moving away from the internal focus driven by Conway’s Law and focusing on real accountability. By trusting decentralized teams to operate within well-defined parameters, and by embedding accountability into the flow of work, organizations can reduce the tendency for centralized functions to create unnecessary work.\nWhen centralized teams work to support the business rather than create work to justify their existence, which they might not do consciously, they can foster a more efficient and effective organization. By adopting a participatory governance model and trusting decentralized teams to handle compliance, organizations can achieve their goals while minimizing the overhead associated with large, process-heavy teams.\n💡OKR: How much of the central teams work have we shifted to to the business process we are having to continuosly check?### Conclusion: Empowering Teams for Better Outcomes\nThe challenge for many organizations is ensuring that central control functions are embedded, via people, process or technology to support the business. By embedding compliance into daily operations, decentralizing decision-making, and adopting a participatory governance model, organizations can shift from creating rituals to achieving real progress.\nUltimately, by distributing control and trusting decentralized teams, organizations can reduce inefficiencies, improve accountability, and ensure that their control functions drive meaningful outcomes rather than justifying their existence.\nThe future is decentrlized. Central team need to delegate and create products that are able to work at the edge!\nThe views, thoughts, and opinions expressed in this blog are solely my own and do not necessarily reflect the views, positions, or policies of my employer or any other organization I may be affiliated with. The information provided on this blog is for general informational purposes only and should not be considered as legal, financial, or professional advice\n","date":"12 October 2024","externalUrl":null,"permalink":"/posts/rethinking-central-control-functions/","section":"Posts","summary":"","title":"Rethinking Central Control Functions: Moving from Rituals to Real Accountability","type":"posts"},{"content":"The process of decision-making is a cornerstone of effective organizational management and personal leadership. For hundreds of years, traditional hierarchical structures have handled decision-making processes, where the chain of command dictates how decisions are made. Basically command and control 🛂.\nIn such organizations, one simply asks their boss to make a decision. Superiors are often happy to \u0026ldquo;help\u0026rdquo; as it reinforces their status, fulfils their primal need to feel needed, and personifies their control over the group.\nMathew Barzum, in “The Power of Giving Away Power*”*talks very powerfully(excuse the pun) about this in his book, where the engrained belief that If you let go of hierarchy, chaos will reign…or so many leaders believe!However, in decentralized organizations, autonomy is pushed to the edge, empowering individuals at all levels to make decisions. The principle here is simple: only centralize what will accelerate the edge. This concept is very very very applicable to shifting things left. See my post series on Shifting Compliance Left.\nIf you let go of hierarchy, chaos will reign…or so many leaders believe\nThe way decisions are made DOES MATTER and impacts the efficiency, morale, and success of a group. Dennis Bakke talks extensively about this in his book “The Decision Maker” or the “Joy at Work” in what he calls the Advice model. This model is based on the importance of treating people like people and not cogs (or kids!) ⚙️. We are all unique, we are all creative thinking individuals, we are capable of learning and we believe we are capable of making decisions, is the TL;DR in the Harvard Business Review\u0026rsquo;s interview “Organizing for Empowerment: An Interview with AES’s Roger Sant and Dennis Bakke”.\nUnderstanding various decision-making processes and choosing the appropriate one for each situation can lead to more informed, inclusive, and effective outcomes. This post explores different decision-making methods and emphasizes the importance of determining how to decide, focusing particularly on the consent-based decision-making approach which is based on the sociocracy method with origins in the Quakers. ⚠️I am aware at this stage a bunch of bias will kick in so it really is up to you if you want to read on if you curious to learn new things!⚠️\nImportance of Decision-Making Processes # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#importance-of-decision-making-processes\nGood decision-making processes are crucial because they affect not only the quality of the decisions but also the buy-in and satisfaction of the group members involved. Some reflection 🤔possible as we go through our iterative transformations? Effective decision-making processes can enhance transparency, accountability, and inclusiveness, leading to stronger and more sustainable decisions. Conversely, poor decision-making can result in confusion, conflict🤼, and disengagement among team members.\nThese tensions are what we normally not good at managing and do not really lead to generative conflict and tends to pivot to interpersonal conflict. We will explore Principled Disagreements in future posts.(Source: theready)\nTypes of Decision-Making (Main ones) # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#types-of-decision-making-(main-ones)\nAutocratic Decision-Making: Tyranny of the Supreme Leader Autocratic decision-making is where a single leader makes decisions without input from others. This method can be efficient in situations requiring quick decisions, but it often leads to low morale and disengagement among team members, who may feel their opinions and contributions are undervalued. For example if there is a fire in the building you want one person to be in charge🔥 **Majority Vote:**This could be seen as the tyrannyof the Majority? Majority voting involves making decisions based on the preference of the majority of the group. While this method is democraticand can prevent the dominance of a single leader, it can marginalize minority opinions and lead to polarization within the group. This can also have interesting outcomes, e.g. Brexit **Consensus:**This could be called Tyranny of the Minority? Consensus requires that all members of the group agree on a decision. This method ensures inclusiveness and broad agreement but can be time-consuming and may give disproportionate power to those who disagree, leading to a \u0026ldquo;tyranny of the minority\u0026rdquo; where a small number of dissenters can block decisions. Consent Decision-Making Consent decision-making, a cornerstone of sociocracy, asks whether anyone has a reasoned and paramount objection to a proposal. This method balances inclusiveness with efficiency, ensuring that decisions do not negatively impact the group while avoiding the pitfalls of consensus and majority vote systems. The really cool🆒thing is a group can use the consent method to decide how they decide, and hence it could be that they decide to give all the decision making authority to one person, which in this case would be subjecting themselves by agreement to the autocratic method…. but this would be by choice and again could be the right thing to do!\nConsensus(binary) vs Consent (range of tolerance)\nAnother important thing to remember is that Consent is NOT the same as Consensus(binary). Consent (range of tolerance) takes into account the extent to which people are willing to tolerate a decision – whether they will accept and endorse it, even if it isn\u0026rsquo;t their top preference. In other words, while individuals might not be enthusiastic about the decision, they can manage to accept it.\nSo is there another way? Dynamic Governance and Consent-Based Decision-Making # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#so-is-there-another-way-dynamic-governance-and-consent-based-decision-making\nFirstly this is not a binary decision. One has to choose the right decision making process for each situation. Gustavo Razzetti @ fearless culture, has a great postwith a cool quadrant on how to potentiall go about this (who does not love a nice quadrant 😀).\nDynamic governance, or sociocracy, employs consent-based decision-making to create a more collaborative and responsive organizational structure. In this system, decisions are made when there are no significant objections, and objections must be based on the group\u0026rsquo;s aims and needs, not personal preferences, so objections need to be empirical📐. This method encourages members to express concerns and work collaboratively to address them, leading to decisions that are broadly supported and more resilient.\nIntegrating Objections is key as this is the fundamental feedback loop improves the decisions and increase the buy-in from the group. You can see how this starts to link up with Agile practices or for those that love the finances busy work (not), practices like “Beyond budgeting” so well presented by Bjarte Bogsnes the Senior Advisor for Performance Frameworks at Equinor🛢️ in this very entertaining 17min video.\nSo how does Consent Method work in practice: # In a nutshell it follows the following steps.\nProposal Presentation: A proposal is presented to the group. Anyone is empowered to present a proposal to improve value or reduce risk. Clarifying Questions: Members ask clarifying questions to understand the proposal fully. This is not an opportunity to raise other proposals. Focus is key. Quick Reactions: Members give quick, initial reactions to gauge the overall sentiment. Remember, reactions on the proposal. Consent Rounds: Members express any objections. Objections must be reasoned and related to the group\u0026rsquo;s objectives. Integrating Objections: The group works together to address objections and modify the proposal if necessary. Is it safe enough to try? Final Consent Round: The modified proposal is presented for final consent. 💡Is it safe enough to try?All of this is done using Roundsto ensure everyone\u0026rsquo;s voice is heard. Round are key for high performing teams given transparency is at the core. And here is Mural(source: fearlessculture) that helps you get started . Who doesn\u0026rsquo;t love a good Mural 😉\nIs this a pipe dream? # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#is-this-a-pipe-dream\nWell a growing number of organizations use similar decision-making methods to enhance inclusivity and effectiveness and they not small. You might recognise some:\nInformed Captainsat Netflix: Netflix employs a model where decisions are made by those with the most expertise, who then inform and seek input from others, ensuring decisions are well-informed and broadly supported. - I can imagine some people thinking at this stage and rolling their eyes, yes but we not Netflix…. Early Dissent and Commit at AWS: Amazon Web Services encourages early dissent and debate during decision-making but expects commitment to the decision once it is made. This fosters thorough consideration of alternatives and unified execution. – more reinforcement bias at this stage…. we not AWS Advice Processat AES (Energy) by Dennis Bakke: AES uses an advice process where decision-makers must seek advice from those who will be affected by the decision and those with expertise. This ensures diverse input and informed decisions. — may be this one gets you thinking… that is if you have already abandoned this article ;-) But there are many more:\nThe Zulu Nation in South Africa (link) – nearly 100 years practicing this. Buurtzorg, a home-care organization in The Netherlands with 14,000 employees (link) – over 20 years The Paris Agreementon climate change (link). Yes I know…. where has that landed… but think about it… it must be really hard to get all those people to agree in the first place… doing is another thing! The Internet Engineering Task Force (IETF) – (RFC 7282: On Consensus and Humming in the IETF (rfc-editor.org)). Read beyond the Title, the word Consensus is misleading. These guys take *small (NOT)*decisions… like how the internet runs ;-). Sun Microsystems Intel GitLab Chef Software Qatar Airways Zalando (McKinsey:Safe Enough to Try interview with their CEO) Autodesk UK Cooperatives (Link) Etc Etc Etc So how does this help an organization? # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#so-how-does-this-help-an-organization\nIf you really want a responsiveorganization that adapts, it\u0026rsquo;s essential to consider the four dimensions of organizational needs:\nResponsiveness, Participation, Doing, and Agreeing. These dimensions help frame how decisionsare made and how work is carried out within the organization. I will not go into the 4 into detail here but focus more on the decisionneeds.\nhttps://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#anchor\nSo this is where Consent-based decision-making facilitates effective execution by ensuring that decisions are well-supported and aligned with the organization\u0026rsquo;s goals by having good agreements. Lets face it we really do not have strong explicit agreements that are down on paper📜 most of the time. This means one party understood it in one way, another in another and another has selective memory!🧠\nSo long story short, Agreements are key and tapping into collective intelligence 🐝 to create and evolve decisions reduces how blindspots and increases empathy for others reality, a very real reality for them, despite you might not see it! This involves:\nClarifying WHY: Ensuring everyone understands the reasons behind decisions. And keep it simple here\u0026hellip;.no fluff🦙. Designing Proposals: Crafting proposals collaboratively - Proposal or Radiating Intent are fundamental! Getting in writing📄 Evaluating and Evolving: Regularly evaluating decisions and making necessary adjustments. We see this is architecture all the time\u0026hellip;. any architecure that does not change it a dead architecture (tech wise). Ensuring Safety: Making sure decisions are good enough and safe enough to proceed. By focusing on agreement through consent, decisions are not only effective but also inclusive and sustainable. Bottom line, you will have a higher rate of adoption, who would not want this!\nBottom line, you will have a higher rate of adoption\nBenefits of Effective Decision-Making Processes # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#benefits-of-effective-decision-making-processes\nGoes without saying this all makes sense and is perfectly logic right? Yet we do very little of this. Implementing effective decision-making processes like consent-based decision-making can create happier, more transparent, and more efficient workplaces. By involving the right (not everyone) people and considering diverse perspectives (everyone\u0026rsquo;s voice📢), organizations can make stronger decisions that are more likely to be supported and successfully implemented.\nI am sure you have sometimes asked yourself, why do they not adopt a way of working? why do they not just do it? why do they not get it? well ask yourself if they had any say in the process directly or indirectly, have they been part of the process, contribute, provide feedback, raise blind spots etc?\nSo how could I start? # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#so-how-could-i-start\nLike everything, slowly🦥. We not very good at understanding two basic realities at play all the time in organizations of people. Firstly if we truly People Positive (and NOTdeterministic robots that are predictable!), that People are naturally motivated, capable of self-direction, and worthy of trust and respect (refer to Dennis Bakke in this article) and secondly, be Complexity Conscious, Organizations are complex systems that can\u0026rsquo;t be predicted or controlled. If you try mass change, the organization WILL kick back. (parts sourced from : https://www.theready.com/)\nOne VERY basic place to start is to start using rounds. This will force those time hoarders in meeting like me to practice a bit more of active listening and get all the many voices of our very capable people in the room heard.\nAnd as a good old English proverb says \u0026ldquo;Softly, softly, catchee monkey\u0026rdquo;🐒, which basically means that if do not rush or if you avoid being too hasty, then eventually you will achieve your goal - in other words, be patient.\nConclusion # https://bp365.sharepoint.com/sites/DeveloperIdentityPlatformsLT/SitePages/Deciding-how-to-decide.aspx#conclusion\nDeciding how to decide is a critical step in creating effective and sustainable organizations. By understanding and implementing various decision-making methods, particularly exploring ones like consent-based decision-making, organizations can enhance inclusivity, transparency, and effectiveness. These processes ensure that decisions are well-informed, broadly supported, and aligned with the group\u0026rsquo;s goals, leading to better outcomes and a more engaged and satisfied workforce.\nFor more detailed information on the principles and applications of sociocracy, refer to resources from Sociocracy For All, Netflix\u0026rsquo;s culture page, and articles on the advice process by Dennis Bakke (source: Corporate Rebels) and AWS\u0026rsquo;s decision-making methods.\nAs always, I have written this for me firstly as I am a believer that if you write things down you learn🏫 and to share with others my learning process or trying to make sense of things.\n","date":"28 June 2024","externalUrl":null,"permalink":"/posts/deciding-how-to-decide/","section":"Posts","summary":"","title":"deciding how to decide","type":"posts"},{"content":"The \u0026ldquo;Three Lines of Defense\u0026rdquo; model has been a cornerstone in risk management and corporate governance for years. However, as organizations evolve, there\u0026rsquo;s a growing sentiment that simply adopting this model without adapting it to modern circumstances can hinder rather than help. Let\u0026rsquo;s delve deeper into the three core concepts embedded in the terminology of \u0026ldquo;Three\u0026rdquo; \u0026ldquo;Lines\u0026rdquo; of \u0026ldquo;Defense\u0026rdquo; and explore how they can be interpreted and improved upon for the dynamic nature of today\u0026rsquo;s organizations.\nThe Power and Peril of \u0026ldquo;Three\u0026rdquo; # At first glance, having three distinct areas might seem like a robust system. However, without aligned and shared goals, these lines can operate in silos, sometimes working against each other.\nIt\u0026rsquo;s paramount to remember that decisions in one line can resonate or impact across all three. The danger lies in achieving a \u0026ldquo;local maximum,\u0026rdquo; where decisions that optimize one line\u0026rsquo;s function might be detrimental when viewed from a broader organizational perspective. Mckinsey, in this article highlights the need to drive agility in control functions (Second Line), given their impact on operations, hence there is a call to action if we want to have sustainable compliance in place. Thus, the real challenge is ensuring that these three lines communicate, coordinate, and act towards a shared, global objective, not just because the auditor says or the policy states, we need to question the outcome we trying to achieve.\nThe \u0026ldquo;Independence\u0026rdquo; theatre # Blending does not mean you sacrifice independence. The terms \u0026ldquo;Segregation of Duties\u0026rdquo; and \u0026ldquo;Independence\u0026rdquo; create emotional reactions and I have seen them be consciously or unconsciously weaponised. Clarissa Lucus, author of Beyond Agile Auditing, must be the first book I read that starts to make a dent 🔨 in this domain for the first time, calling out the compliance theatre that hides behind the segregation of duties rules. I strongly believe this is not a dichotomy and they can coexist and meet the rules as the author states in her book, we just need to be curious and peel back the onion to understand what we trying to achieve and how we can achieve it in a better way.\nThe Rigidity of \u0026ldquo;Lines\u0026rdquo; # In its essence, a line is straight, unbending, and definitive. Such rigidity in the face of complex, modern challenges can be more of a barrier than a boon. If each line remains inward-looking, it only strengthens its identity while potentially severing crucial cross-line connections. This isolation can prevent the collective insight needed for emerging challenges, like understanding the implications of financial data generated by AI. We need to ask ourselves if there is trust between these lines. It would not be the first time I have heard second line say, \u0026ldquo;well they not going to do it so best we check\u0026rdquo;. Trust is good but control is better right?\nThis is where we need to put our focus. Transparency, this includes sharing why second or third line is devising the purchase of product for example to control a symptom versus the root cause of something in first line, for auditing (3LOD) the by-product of a bad process versus again understanding the nuances of the true cause, which could be under resourcing in First line, Small but incremental demand on time from the same, unclear requirements and lack of explicitness inter alia. Trust is built on Communication, Transparency and Honesty. Do we talk enough? Do we actively listen enough?\n“Each time you give trust in advance of demonstrated performance, you flirt with danger. If you’re risk-averse, you won’t do it. And that’s a shame, because the most effective way to gain the trust and loyalty of those beneath you is to give the same in equal measure.” ― Tom DeMarco\nIn practice, these \u0026ldquo;lines\u0026rdquo; should be more fluid, allowing collaboration and dialogue. It\u0026rsquo;s crucial to ask: Are our interactions with other lines sporadic and task-focused or strategically embedded in our routine?\nThe Restrictiveness of \u0026ldquo;Defense\u0026rdquo; # To defend is to resist, to guard against something. This stance, by nature, is less receptive to external perspectives. The language in the audit and risk sectors leans heavily towards restriction and reaction: control, risk, barriers, mitigation.\nRarely does it encompass the proactive, positive aspects like seizing opportunities or reinforcing desired behaviours. When compliance becomes solely about avoiding the negatives, it misses out on promoting and rewarding the positives. The emphasis on punitive measures over positive reinforcement can stagnate growth. How often do we commend someone for proactive compliance or for spotting an opportunity rather than a risk?\nAn alternative iteration of the 3LOD # The traditional model of the \u0026ldquo;Three Lines of Defense\u0026rdquo; is not obsolete, but it requires a contemporary interpretation to remain effective.\nOrganizations need to prioritize creating shared goals across all three lines. The absence of these shared objectives is a clear indication of silos that can impede early detection of unprecedented challenges. Teams must lean into issues that traverse these lines, ensuring fluidity in operations and flexibility in organizational constructs. Remember, sometimes the best defense is a good offense – and fostering a proactive approach can be the game-changer in navigating the intricate landscape of modern risk management and compliance. Maybe we need to rethink governance, maybe new ways of governing for example participatory governance. Jurriaan Kamer put this nicely in his blog post: \u0026ldquo;When properly empowered, each person in an organization can act as a sensor, discerning how things are running, and deliver rich data to steward this process. Lets work together and lean into those fixed lines to find shared goals!\n","date":"3 December 2023","externalUrl":null,"permalink":"/posts/three-lines-of-defense-have-things-have-moved-on/","section":"Posts","summary":"","title":"Three Lines of Defense 2.0?","type":"posts"},{"content":"VivingIT is a place where I can write, not just as vehicle to share ideas with others but also a way to understand them better myself.\nWriting is the process by which you realize that you do not understand what you are talking about. Importantly, writing is also the process by which you figure it out.\nWriting about something teaches you about what you know, what you don’t know, and how to think. Writing about something is one of the best ways to learn about it. - Source Why Write? (fs.blog)\n💡The views, thoughts, and opinions expressed in this blog are solely my own and do not necessarily reflect the views, positions, or policies of my employer or any other organization I may be affiliated with. The information provided on this blog is for general informational purposes only and should not be considered as legal, financial, or professional advice© 2024 Denis Ontiveros Merlo.\n","date":"3 July 2023","externalUrl":null,"permalink":"/about/","section":"","summary":"","title":"About this site","type":"page"},{"content":"","date":"30 November 2022","externalUrl":null,"permalink":"/tags/news/","section":"Tags","summary":"","title":"News","type":"tags"},{"content":"Welcome to the second instalment of our blog series on rethinking the three lines of defence model. Building on our previous discussion, where we emphasized the importance of putting customers at the core of compliance, this blog post delves deeper into the concept of \u0026ldquo;shifting compliance left.\u0026rdquo; By practically creating products and services for the internal customers of the first line of defence, organizations can enable them to take on their accountability in the most effective and efficient way. The objective is to drive the right behaviours and make it easier for the first line to do the right thing, rather than relying on heavy-handed compliance measures. This concept draws inspiration from embedding security into the software development process and leverages behavioural economics frameworks. Let\u0026rsquo;s explore how shifting compliance left can lead to transformative outcomes and the need for aligning efforts, resources, and budgets.\nCreating Products that Drive the Right Behaviour # To facilitate a shift in compliance, organizations must focus on designing and offering products and services that empower the first line of defence. Just as embedding security into the software development process transformed the security landscape, we can apply similar principles to compliance. The aim is to make it easier for the first line to meet compliance requirements and take ownership of their responsibilities. By providing user-friendly tools, streamlined processes, and automated solutions, organizations can nudge and influence behaviour positively, enabling the first line to seamlessly integrate compliance into their daily workflow.\nTreat the cause and not the symptoms # In what I regard staple reading for any person that considers themselves to be compliance or security professionals, Ian Levy, the NCSC’s departing Technical Director in 2022 wroteinter alia, \u0026ldquo;We’re still treating the symptoms, not the cause\u0026rdquo; and we need to focus more on creating products and processes that drive the right behaviours. Although his will also be subject to its own post, Behavioural economics provides valuable insights into human decision-making and behaviour. Leveraging this knowledge, organizations can design products and services that align with how people naturally think and act. By understanding cognitive biases, motivations, and decision heuristics, compliance processes can be designed to be more intuitive, engaging, and aligned with the first line\u0026rsquo;s workflow. For example, implementing frictionless recertification processes or gamifying compliance activities can create a sense of ownership and encourage active participation.\nPut your money where your mouth is: Reallocating Effort, Resources, and Budgets # If I would to ask you or anyone in the compliance community, would you prefer to get the controls first time right in the first line or would you prefer to catch the issues in the second or third line, I bet you nobody would raise their had for the latter. To truly shift compliance left, organizations must reflect this transformation in the distribution of effort, resources, and budgets. This requires a strategic approach that focuses on the gradual transfer of responsibilities and investments to the first line of defence. Not only does it require strategic thinking, but also letting go of traditional mental models that are emotionally connected to the base of the these compliance communities and professionals. We need more shared goals if we are to be successful, establishing objectives and key results (OKRs) and key risk indicators (KRIs) that drive this shift can help guide the organization\u0026rsquo;s progress. Allocating more resources towards developing products and services that facilitate first line compliance, such as identity and access management, change management, and frictionless recertification, is crucial. The goal is to pivot the flow of work towards the first line, rather than burdening them with additional compliance processes. Take is cheap. Transfer money and resource from your compliance budget to the constraint the next constraint in the system. The first line and the product or services they use. Remember at any point in time there can only be one constraint in the system, and as pure Theory of Constraints tell us, **SUBORDINATE everything else to the constraint,**and then, only them move to the next one.\nDriving Cultural Change and Organizational Alignment # Shifting compliance left is not solely about technological solutions or process changes; it requires a cultural shift within the organization. By emphasizing a collaborative and supportive approach, organizations can foster a culture of accountability, where compliance becomes embedded in the fabric of everyday work. This requires leadership commitment, effective communication, and a shared vision across all levels of the organization. When the entire organization aligns around the principle of driving compliance from within the first line, a significant and sustainable change can be achieved.\nConclusion # Shifting compliance left presents an opportunity to transform the compliance landscape by empowering the first line of defence. By creating products and services that drive the right behaviours and aligning efforts, resources, and budgets accordingly, organizations can foster a culture of accountability and efficiency. Leveraging insights from behavioural economics and following the principles of embedding compliance into workflow, organizations can make compliance an integral and seamless part of their daily operations. With a collaborative and strategic approach, organizations can truly put their money where their mouth is and drive impactful change in their compliance practices. Stay tuned for the next instalment of our blog series as we explore more thought provoking approaches to the compliance domain.\n","date":"30 November 2022","externalUrl":null,"permalink":"/posts/shift_compliance_left/","section":"Posts","summary":"","title":"Shift Compliance Left: Put Your Money Where Your Mouth Is","type":"posts"},{"content":"","date":"30 November 2022","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"In the world of corporate governance and risk management, the three lines of defence model has long been hailed as a best practice framework. However, one critical aspect that often goes unnoticed is the identification of the true customers within each line of defence. By taking a customer-centric and product-led compliance approach, organizations can foster the right behaviours, streamline their control systems, and achieve a \u0026ldquo;get it right the first time\u0026rdquo; mentality in the first line of defence. Join me in this multi part article, where we will explore this misconception, delve into the importance of understanding the real customers, and highlight the benefits of re-evaluating our approach to the three lines of defence.\nThe Three Lines of Defence: A Recap # Before diving into the misconceptions, let\u0026rsquo;s revisit the three lines of defence model. The three lines of defence or 3LOD model was developed by the Institute of Internal Auditors (IIA) circa 2013. It has since become the most widely adopted framework for risk management and control in organizations around the world The first line of defence comprises the operational management and staff directly involved in day-to-day activities. The second line consists of risk management and compliance functions, providing oversight and support. Finally, the third line represents independent assurance, often performed by internal or external audit.\nHere is a picture of this model as it stands today, and the defacto for the compliance community. This model gives the sense of order and structure, when in reality the lines gravitate to blur and converge in modern organizations, creating tensions not always productive, that we will discuss in a later post.\nSource: tree_lines_of_defence_diagram.jpg (2339×1656) (iia.org.uk)## The Customer Conundrum\nIn the realm of compliance, it is essential to recognize that the true customers are not internal stakeholders or control functions, but the external customers who rely on the organization\u0026rsquo;s products or services. This customer-centric viewpoint brings a fresh perspective to the three lines of defence model, enabling organizations to align their efforts and investments more effectively.\nReimagining the First Line of Defence # By focusing on the actual customers, organizations can empower the first line of defence to be proactive and quality-driven. Implementing a product-led compliance approach means embedding controls within the products and services themselves, ensuring that compliance requirements are met seamlessly. This approach fosters a mindset of getting controls \u0026ldquo;first time right\u0026rdquo; and reduces the need for extensive rework or corrective measures downstream.\nUnderstanding the Second Line # In the traditional model, the second line of defence tends to be seen as the primary driver of risk management and compliance activities. However, by embracing a customer-centric approach, organizations can leverage the second line to provide guidance, support, and tools that enable the first line to deliver customer-focused compliance. This shift allows the second line to empower the first line rather than overshadow it, creating a more harmonized and effective control environment.\nThe Role of the Third Line # The third line of defence, typically internal or external audit, plays a crucial role in providing independent assurance to senior management and the board of directors. By recognizing the real customers as the ultimate recipients of the organization\u0026rsquo;s products or services, the third line can focus on assessing the effectiveness of controls in meeting customer needs, providing valuable insights to enhance customer satisfaction and mitigate risks.\nBenefits of a Customer-Centric Approach: \u0026ldquo;shift audit left\u0026rdquo; # I will take the liberty of coining the term \u0026ldquo;shift audit left\u0026rdquo;, where adopting a customer-centric and product-led compliance approach yields several benefits for organizations. Firstly, it creates a shared understanding of the importance of compliance throughout the organization, as all employees directly contribute to delivering compliant products and services. Secondly, it drives a culture of accountability and continuous improvement, as the first line takes ownership of controls from the outset. Lastly, it optimizes resource allocation, ensuring that investments in risk management and compliance are directed towards initiatives that directly impact customer satisfaction and organizational success.\nConclusion # Reevaluating the three lines of defence model through a customer-centric lens allows organizations to shift their focus from an inward view of compliance to one that aligns with customer needs and expectations. By empowering the first line of defence, organizations can achieve a \u0026ldquo;get it right the first time\u0026rdquo; approach, streamlining control systems and avoiding unnecessary costs. A customer-centric and product-led compliance strategy not only enhances customer satisfaction but also instills a culture of compliance throughout the organization, positioning it for long-term success in today\u0026rsquo;s rapidly evolving business landscape\n","date":"20 November 2022","externalUrl":null,"permalink":"/posts/rethinking_3lod/","section":"Posts","summary":"","title":"Rethinking the Three Lines of Defence: Putting Customers at the Core of Compliance","type":"posts"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"}]