[{"data":1,"prerenderedAt":366},["ShallowReactive",2],{"blog-index:en":3},[4,218],{"id":5,"title":6,"author":7,"body":8,"date":204,"description":205,"extension":206,"meta":207,"navigation":208,"path":209,"seo":210,"stem":211,"tags":212,"__hash__":217},"blog_en/blog/contractor-separation/en.md","Contractor Separation: Two Layers Instead of One","Aptli",{"type":9,"value":10,"toc":193},"minimark",[11,16,20,23,27,30,37,43,49,55,58,62,65,71,77,80,84,87,103,106,110,113,120,137,144,147,150,154,157,160,164],[12,13,15],"h2",{"id":14},"the-situation","The Situation",[17,18,19],"p",{},"More and more of the organizations we work with run shared platforms where multiple parties operate on the same underlying asset data. A utility might have internal crews, a primary construction contractor, and two or three subcontractors all touching the same network. A municipality might have its own staff plus outside engineering firms. It is common — and increasingly unavoidable — for parties who compete with each other to end up working inside the same application.",[17,21,22],{},"The obvious question is how you keep those parties from seeing each other's work. The obvious first answer is \"give each of them a login.\" That gets you authentication, which is necessary but not sufficient. Authentication tells the system who you are. It does not tell the system what you are allowed to see. Without a second layer, everyone who logs in sees everything.",[12,24,26],{"id":25},"the-approaches-that-do-not-quite-hold-up","The Approaches That Do Not Quite Hold Up",[17,28,29],{},"There are four common approaches, and each has a place. They also each have limits worth being honest about.",[17,31,32,36],{},[33,34,35],"strong",{},"Separate tenant deployments."," Give each contractor their own copy of the application, their own database, their own environment. This is real isolation and there are cases where it is the right answer — usually when the parties share nothing and will never collaborate. It gets expensive fast, and it defeats the reason the platform exists if the whole point was collaboration, rollup reporting, or a single map of truth. If most of the data is shared and only a slice is sensitive, separate tenants is overkill.",[17,38,39,42],{},[33,40,41],{},"UI-only hiding."," The most common shortcut. Hide the button, skip the menu item, filter the list view. This is security theatre. Anyone with browser developer tools, a direct API request, or a well-aimed export can retrieve the \"hidden\" data. The record still exists, still flows over the wire, and still appears in bulk exports. It keeps honest users from stumbling onto things; it does not stop anyone who is actually looking.",[17,44,45,48],{},[33,46,47],{},"Application-layer filtering, endpoint by endpoint."," A real step up: enforce the filter in code wherever data is queried. This works — right up until it does not. Security now lives in dozens of query sites. Every new feature is a potential leak. Every refactor is a chance to forget one. This approach tends to be correct at the moment it ships and to drift out of correctness as the codebase grows.",[17,50,51,54],{},[33,52,53],{},"Exporting to separate workspaces."," Copy the data each contractor needs into a workspace only they can see. This is genuinely isolated but the copy goes stale the moment it is made. Now you have a sync problem instead of a visibility problem, and field workers end up looking at yesterday's view of today's work.",[17,56,57],{},"None of these are wrong in every situation. They are wrong as a general-purpose answer to multi-party access on a shared platform.",[12,59,61],{"id":60},"the-two-layer-model","The Two-Layer Model",[17,63,64],{},"Our approach separates authorization into two independent layers that compose.",[17,66,67,70],{},[33,68,69],{},"Admin rights are permissive."," They describe what a user is allowed to do — create a work order, edit a report, delete a stock item. Without an admin right, the default is that you can view data but cannot alter it.",[17,72,73,76],{},[33,74,75],{},"Role restrictions are restrictive."," They describe what a user cannot see or touch at all. Each restriction specifies a model (points, reports, assignments), a field on that model (owner, status, category), a comparison, and a value. Matching records are hidden from members of the role for the specified operations — read, edit, create, delete — independently.",[17,78,79],{},"These layers do not interfere with each other. A field worker can hold the right to edit reports while a role restriction hides any report not authored by them — so they can edit, but only their own. The admin right grants the capability; the role restriction narrows the scope. Neither layer needs to know about the other, and that independence is most of the reason the model ages well.",[12,81,83],{"id":82},"why-server-side-field-level-enforcement-matters","Why Server-Side, Field-Level Enforcement Matters",[17,85,86],{},"Role restrictions are applied on the server, before data leaves the database. This is the part that matters in practice:",[88,89,90,94,97,100],"ul",{},[91,92,93],"li",{},"The filter applies to every query path — detail pages, list views, API calls, bulk exports, map tiles.",[91,95,96],{},"A user who types a record ID they happen to know into the URL gets a 404 Not Found, because to them the record genuinely does not exist.",[91,98,99],{},"A screenshot from another user's screen is not useful; the data will not load when the restricted user tries to reach it.",[91,101,102],{},"New features inherit enforcement automatically, because they go through the same server data layer.",[17,104,105],{},"UI-level hiding fails every one of these tests. Application-layer filtering passes them only if the developer remembers to apply the filter at each new query site. Field-level restrictions enforced at the server turn the question from \"did we remember?\" to \"did the data match the rule?\" — which is the question we actually want the system to be answering.",[12,107,109],{"id":108},"a-worked-example","A Worked Example",[17,111,112],{},"Two contractors on the same fibre build. Both use the same map, both consume the same shared base layers, both log reports against their own work.",[17,114,115,116,119],{},"Create a role named ",[33,117,118],{},"Contractor A"," with a single restriction:",[88,121,122,125,128,131,134],{},[91,123,124],{},"Model: Point",[91,126,127],{},"Field: owner",[91,129,130],{},"Comparison: =",[91,132,133],{},"Filter value: Contractor B",[91,135,136],{},"Permissions blocked: read, edit, create, delete",[17,138,139,140,143],{},"Add Contractor A's users as members. Do the mirror for ",[33,141,142],{},"Contractor B",". That is the entire configuration.",[17,145,146],{},"Contractor A's crews now see their own points, the shared layers, and nothing from Contractor B. If they open a list of points, Contractor B's records are not in it. If they export to CSV, the export is filtered. If they guess the numeric ID of a Contractor B point and paste it into the URL, they get a 404 Not Found. Contractor B experiences the mirror image. Neither side knows how much work the other has done, where it is, or when it was updated.",[17,148,149],{},"The shared base layers — cable routes, poles, duct infrastructure — remain visible to both, because no restriction applies to them. Collaboration is preserved where it is wanted; isolation is enforced where it is required. The platform does not have to choose between the two.",[12,151,153],{"id":152},"when-separate-tenants-are-still-the-right-answer","When Separate Tenants Are Still the Right Answer",[17,155,156],{},"The two-layer model is not a universal answer. If two parties share nothing, never collaborate, never produce a joint report, and have regulatory reasons to live on physically separate infrastructure, then separate tenants is the honest choice. What the two-layer model replaces is the far more common case where parties share most of the platform and need to hide a specific slice. That is the case where separate tenants wastes money, breaks reporting, and slows work down, and where UI-only hiding leaks.",[17,158,159],{},"The test we apply is simple: if the parties would benefit from seeing the same base layers, running the same reports, and working inside the same map, they belong on the same platform — with real separation enforced at the level where it actually holds.",[12,161,163],{"id":162},"summary","Summary",[88,165,166,169,172,175,178,181,184,187,190],{},[91,167,168],{},"Multi-party work on shared platforms is increasingly common in utilities, telecom, and municipal operations, and increasingly includes parties that compete with each other.",[91,170,171],{},"Authentication alone does not isolate users; it only identifies them. Everyone who logs in still sees everything unless a second layer is added.",[91,173,174],{},"Separate tenant deployments offer real isolation but defeat the point of a shared platform when parties need to collaborate on most of the data.",[91,176,177],{},"UI-only hiding is security theatre — the data is still there and retrievable through developer tools, the API, or exports.",[91,179,180],{},"Application-layer filtering is better but tends to drift out of correctness as the codebase grows and new features are added.",[91,182,183],{},"The two-layer model separates authorization into permissive admin rights (what you can do) and restrictive role restrictions (what you cannot see), enforced at the server on a field-by-field basis.",[91,185,186],{},"Server-side field-level enforcement means restricted data genuinely does not exist from the restricted user's perspective — not in the UI, not in the API, not in exports, not at a guessed URL.",[91,188,189],{},"The worked configuration is a single role per contractor, and the result is isolation where it is required with shared layers preserved where collaboration is wanted.",[91,191,192],{},"Separate tenants still have their place when parties share nothing; the two-layer model is the better answer for the far more common case where parties share most things and need to hide a slice.",{"title":194,"searchDepth":195,"depth":195,"links":196},"",2,[197,198,199,200,201,202,203],{"id":14,"depth":195,"text":15},{"id":25,"depth":195,"text":26},{"id":60,"depth":195,"text":61},{"id":82,"depth":195,"text":83},{"id":108,"depth":195,"text":109},{"id":152,"depth":195,"text":153},{"id":162,"depth":195,"text":163},"2026-04-16","When multiple parties share a platform — staff, subcontractors, even competing contractors — authentication alone does not isolate them. Here is how we think about building that separation in a way that actually holds up.","md",{},true,"/blog/contractor-separation/en",{"title":6,"description":205},"blog/contractor-separation/en",[213,214,215,216],"authorization","multi-tenant","contractor-separation","security","9q4x005zlHcLMnCXRCZosdggxV1Y6Wq3KyyPkMDqqE0",{"id":219,"title":220,"author":7,"body":221,"date":355,"description":356,"extension":206,"meta":357,"navigation":208,"path":358,"seo":359,"stem":360,"tags":361,"__hash__":365},"blog_en/blog/data-sovereignty/en.md","Data Sovereignty: The New Geopolitical Battleground",{"type":9,"value":222,"toc":340},[223,227,230,233,236,239,242,246,249,252,255,259,262,267,270,274,277,281,284,288,291,295,298,302,305,309,312,314],[12,224,226],{"id":225},"what-is-data-sovereignty-and-where-did-it-come-from","What Is Data Sovereignty and Where Did It Come From?",[17,228,229],{},"Data sovereignty is the principle that data is subject to the laws and legal jurisdiction of the country in which it is collected, stored, or controlled. At its core it asks two questions: which country's laws govern the data, and which entities can legally compel access to it?",[17,231,232],{},"The issue has been building since cloud computing made physical server location irrelevant to data control. When a Canadian municipality stores records on a platform owned by a US corporation, those records are potentially reachable by the US government under the Clarifying Lawful Overseas Use of Data Act (CLOUD Act), enacted in 2018. The CLOUD Act's reach is not limited to companies headquartered in the United States. It can extend to any provider subject to US jurisdiction, including foreign companies with US operations, offices, or contracts with US customers. In practice, most major cloud and software vendors fall within that reach, which means Canadian data stored on those platforms carries real exposure regardless of where the servers sit.",[17,234,235],{},"For years this was treated as a niche legal concern. What changed is the geopolitical environment. Trade tensions between the US and China, questions about the reliability of American technology partners, and a wave of high-profile data breaches pushed governments to treat digital infrastructure the way they treat physical infrastructure: as something that needs to be controlled domestically or not at all.",[17,237,238],{},"Europe moved first and most decisively. The EU's GDPR, enforced since 2018, established the template. Since then the EU has layered on the Data Act, the Digital Operational Resilience Act (DORA), and a raft of additional regulation. By 2026 the EU had formally adopted a Declaration for European Digital Sovereignty and committed tens of billions into domestic cloud and semiconductor capacity. The framing there has become explicitly geopolitical: Europe sees itself caught between a market-driven American digital ecosystem and a state-controlled Chinese one, and has concluded that dependence on either is a strategic liability.",[17,240,241],{},"Canada is following the same trajectory. Prime Minister Mark Carney made data sovereignty a stated policy priority in November 2025. A new federal private sector privacy statute is expected in 2026. Quebec's Law 25 already imposes GDPR-comparable requirements at the provincial level, with penalties reaching $25 million or 4% of worldwide turnover. The pattern is clear and accelerating globally, with Brazil, Singapore, and other jurisdictions building comparable frameworks.",[12,243,245],{"id":244},"why-it-matters-now","Why It Matters Now",[17,247,248],{},"The gap between data residency and data sovereignty is the central practical problem. An organization can configure its tools to store data in Canadian data centres and still be fully exposed to foreign legal process if the software vendor falls within US jurisdiction. In June 2025, Microsoft France acknowledged before a French Senate committee that it could not guarantee data stored in France would be shielded from US judicial requests. That admission crystallized the issue for European policymakers and produced the same conversation in Canada shortly after.",[17,250,251],{},"For operators of critical infrastructure such as utilities, municipalities, and telecommunications providers, the stakes are especially high. Field asset data, grid topology, work order histories, and inventory records increasingly qualify as sensitive national infrastructure under emerging regulatory frameworks. A foreign government gaining access to that data through a cloud provider's legal obligations is not a theoretical risk. It is a structural one built into most organizations' current vendor relationships.",[17,253,254],{},"Beyond national security, there is an immediate procurement consequence. Federal and provincial RFPs in Canada increasingly require documented data sovereignty positioning. Organizations selling into the public sector without the ability to answer sovereignty questions in writing are being disqualified at the procurement stage. The compliance burden is real and it is moving downstream from governments to their technology suppliers.",[12,256,258],{"id":257},"a-multi-layer-approach-to-sovereignty-controls","A Multi-Layer Approach to Sovereignty Controls",[17,260,261],{},"Addressing data sovereignty is not a single configuration decision. It requires controls at the jurisdictional, architectural, contractual, operational, and governance levels simultaneously. The following layers represent the current standard of practice.",[263,264,266],"h3",{"id":265},"layer-1-jurisdictional-architecture","Layer 1: Jurisdictional Architecture",[17,268,269],{},"This is the foundation. Use cloud providers with legally isolated domestic subsidiaries, not just domestic data centres. Implement customer-managed encryption keys so the provider cannot hand over readable data without your direct involvement. Map every data path including backups, disaster recovery replicas, and vendor support access channels. Sovereignty failures most commonly occur through these side paths rather than primary storage.",[263,271,273],{"id":272},"layer-2-audit-and-evidence-controls","Layer 2: Audit and Evidence Controls",[17,275,276],{},"Regulators and procurement officers are asking for documented proof, not assurances. Implement continuous logging of where data resides and who accessed it. Automate alerts when data crosses a jurisdiction boundary. Maintain audit trails in an immutable format so the evidence record cannot be altered after the fact. These controls serve both compliance and competitive positioning in government sales.",[263,278,280],{"id":279},"layer-3-contractual-and-vendor-governance","Layer 3: Contractual and Vendor Governance",[17,282,283],{},"Every third-party tool in your stack is a potential sovereignty gap. Require data processing agreements with explicit jurisdiction clauses. Prohibit subprocessor data transfers without prior consent. Demand supply chain transparency so you know not just your vendors but your vendors' vendors. Classify workloads by sovereignty criticality and apply controls proportionate to the sensitivity of each.",[263,285,287],{"id":286},"layer-4-privacy-impact-assessments-and-transfer-assessments","Layer 4: Privacy Impact Assessments and Transfer Assessments",[17,289,290],{},"These are the documentary proof layer and are becoming mandatory in more jurisdictions. Quebec requires a Transfer Impact Assessment before personal data leaves the province, with detailed written agreements required for all service providers processing that information. Build PIA and TIA templates into your procurement and vendor onboarding process so they are systematic rather than reactive.",[263,292,294],{"id":293},"layer-5-encryption-and-sovereign-key-management","Layer 5: Encryption and Sovereign Key Management",[17,296,297],{},"Encryption at rest and in transit is baseline. The real control is who holds the keys. If your organization holds the encryption keys, a foreign court order directed at your cloud provider yields nothing usable. This also provides future resilience: quantum computing will eventually challenge current encryption standards, and organizations with mature key management practices will be better positioned to adapt.",[263,299,301],{"id":300},"layer-6-operational-access-controls","Layer 6: Operational Access Controls",[17,303,304],{},"A support engineer based in a foreign country accessing your data for troubleshooting can create CLOUD Act exposure even if the data itself never moved. Restrict operational and support access to approved jurisdictions. Apply time-bounded permissions for any elevated access. Log all access events with enough detail to reconstruct what happened and why. This layer is frequently overlooked and is a common source of compliance gaps.",[263,306,308],{"id":307},"layer-7-governance-and-board-level-accountability","Layer 7: Governance and Board-Level Accountability",[17,310,311],{},"Sovereignty is an ongoing discipline, not a one-time configuration. Designate a Privacy Officer, which is already mandatory under Quebec's Law 25 and expected to be required federally. Establish a data governance function with real authority and a regular audit cadence. Ensure board-level understanding of sovereignty obligations, not just IT-level awareness. Organizations that embed this into governance rather than treating it as an IT project are the ones that hold up under regulatory scrutiny.",[12,313,163],{"id":162},[88,315,316,319,322,325,328,331,334,337],{},[91,317,318],{},"Data sovereignty means data is governed by the laws of the jurisdiction that controls it, not just where it is physically stored.",[91,320,321],{},"The CLOUD Act can reach any provider subject to US jurisdiction, including foreign companies with US operations or contracts. Most major cloud vendors fall within that reach.",[91,323,324],{},"Europe and Canada are both accelerating sovereign data frameworks in 2026, driven by geopolitical pressure and critical infrastructure risk.",[91,326,327],{},"Quebec's Law 25 is already enforcing sovereignty-grade requirements at the provincial level, with federal legislation expected to follow.",[91,329,330],{},"The residency-versus-sovereignty distinction is the single most important concept to internalize: where data sits and whose laws govern it are two different questions.",[91,332,333],{},"Effective controls span seven layers: jurisdictional architecture, audit trails, vendor contracts, privacy impact assessments, encryption and key management, operational access restrictions, and board-level governance.",[91,335,336],{},"Sovereignty failures most often occur through side paths like backups and support access rather than primary storage configurations.",[91,338,339],{},"Organizations that treat sovereignty as a competitive asset rather than a compliance burden are gaining a real procurement advantage, particularly in public sector sales.",{"title":194,"searchDepth":195,"depth":195,"links":341},[342,343,344,354],{"id":225,"depth":195,"text":226},{"id":244,"depth":195,"text":245},{"id":257,"depth":195,"text":258,"children":345},[346,348,349,350,351,352,353],{"id":265,"depth":347,"text":266},3,{"id":272,"depth":347,"text":273},{"id":279,"depth":347,"text":280},{"id":286,"depth":347,"text":287},{"id":293,"depth":347,"text":294},{"id":300,"depth":347,"text":301},{"id":307,"depth":347,"text":308},{"id":162,"depth":195,"text":163},"2026-04-08","Control over data has become inseparable from national security, economic competitiveness, and democratic resilience. Here is where the problem came from, why it matters now, and what organizations can do about it.",{},"/blog/data-sovereignty/en",{"title":220,"description":356},"blog/data-sovereignty/en",[362,363,364],"data-sovereignty","compliance","infrastructure","ZwWKfLB1V90pbI7zHBVfZTuDSX95CAAzrzedY3fcCJo",1776778050403]