Compliance guardrails for regulated delivery

One multinational running on Upsun operates more than 400 websites. Each subsidiary has its own sites, its own team, its own release schedule, and its own local requirements. What they share is one infrastructure control layer: the same access model, the same encryption defaults, the same activity records, the same region and backup policy on every project. Adding the 401st site does not add a 401st set of infrastructure controls for someone to review. 

That is the outcome worth designing for, because every IT leader with a compliance mandate eventually hits the same wall. The engineering team wants to increase velocity. The compliance function needs evidence that nothing has been compromised in the process. 

Historically, the two have been reconciled through processes: manual reviews, change advisory boards, and release freezes before audit windows. That reconciliation works, but it is slow, and it scales badly. What scales is not the number of applications, but the number of regulated releases. A handful of sensitive applications shipping several times a week can generate the same review burden as hundreds of quiet ones, which is why counting applications understates the problem.

The alternative applies the same rigor one layer down, in the platform every team already ships through, so it does not have to be reapplied by each team on each release.

Where guardrails need to live

Key takeaway: Guardrails belong at the platform layer, not the application layer. Anything that has to be correct every single time, regardless of what a team is building, should be enforced structurally rather than checked manually.

The reference architecture separates delivery into two layers with a clear boundary between them: a guardrail layer that the platform applies consistently to every team and every release, and an application layer where teams keep meaningful choices within the capabilities the platform supports.

• Access and identity. Who can deploy to which environment, and under what role, should be defined once and enforced consistently across every project. This is the layer SOC 2 and ISO 27001 access control requirements target: not whether a policy document exists, but whether access is provably scoped and reviewed. Upsun provides role-based permissions across organizations, projects, and environment types. Organization-wide MFA enforcement and SSO are add-on capabilities rather than defaults, so the access model an auditor sees depends on which of them the organization has enabled.
• Encryption and data protection. Encryption at rest and in transit, key management, and secrets handling should be platform defaults, not per-project configuration decisions. A team building a new service shouldn't be deciding whether to encrypt data; that decision should already be made for them.
• Activity records tied to change authorization. Upsun logs deployments, pushes, configuration activity, and environment access on every project automatically, with timestamps, the responsible user, and the resulting deployment state. But execution logs prove what happened, not that it was authorized. Pairing them with pull request review, where a separate approver signs off before merge, is what closes that gap under change management controls. One exception: SSH session records are not directly customer-accessible and may require an Upsun support request during an audit.
• Region selection. Where regulated data can live should be a controlled property of the project, not a convention teams are trusted to follow. On Upsun, a project region is chosen when the project is created, and it then stays a controlled property of that project, inspectable through project state and activity data. It is not declared in the version-controlled configuration, so it is not something a team changes in a pull request. What it does mean is that the answer to "where does this data reside" is a query against live project state, not a document someone has to go verify.
• Backup, recovery, and restoration testing. Automated, scheduled backups with configurable retention per environment type are a baseline expectation under SOC 2's availability criteria and PCI DSS alike, but the schedule is only half the control. Upsun runs automated daily backups of production environments by default, with retention configurable to match the recovery point objective a given framework requires. The other half is the customer's. Choosing a retention period that matches the framework and proving a backup can be restored are decisions the platform does not make for you, and both belong in a regular review cadence.

None of these five guardrails should be something an individual team decides to implement well or poorly. They are the floor every release stands on, applied through the same controls whether the team is shipping a new customer-facing feature or a backend service nobody sees. Retention, region, and access scope are still set per project. What does not vary is the mechanism that sets them or the evidence they produce.

What stays flexible

Key takeaway: Once the guardrail layer is fixed, the decisions above it belong to the team, within the capabilities the platform supports. Compliance doesn't require standardizing the things that do not affect audit posture.

This is the distinction that determines whether a compliance architecture gets adopted or gets routed around. Teams that experience compliance as a constraint on every decision will find workarounds. Teams that experience it as a fixed foundation they don't have to think about, with real freedom above it, will use the system as designed.

• Language and framework. What a service is written in has no bearing on whether access controls, encryption, and audit logging are correctly applied. These stay a team decision.
• Release cadence. Some teams ship multiple times a day; others operate on a slower, more deliberate cycle. Neither pace is more or less compliant, provided the guardrail layer is consistent across both. A standardized delivery pipeline supports both without forcing a uniform release rhythm.
• Architecture and service dependencies. Database choice, caching strategy, internal service boundaries: these are product and technical decisions that belong to the team closest to the problem. The guardrail layer doesn't dictate what a team builds, only how the built thing is deployed, accessed, and evidenced.
• Application-level security and authorization logic. The platform's guardrails secure the infrastructure layer: who can deploy, how data is encrypted, how access is logged. What a team builds on top of that remains squarely their responsibility, including application vulnerabilities, dependency and software composition risk, and their own user authentication and authorization logic. This is the shared responsibility boundary that matters most in practice, and it's worth being precise about it rather than implying the platform covers everything.

Mapping the architecture to specific frameworks

Key takeaway: SOC 2, ISO 27001, GDPR, PCI DSS, and DORA all reward the same thing at the infrastructure layer: control you can demonstrate rather than control you describe, but they are not interchangeable. Each weighs different specifics, and each asks for judgment work that no infrastructure layer supplies on its own.

• SOC 2 Type 2 evaluates whether controls are actually operating over an audit window, typically three to twelve months, not just whether they're documented. Automated access logging and encryption map directly to the Common Criteria for security; automated, tested backups map to the availability criteria. SOC 2 auditors also distinguish execution evidence (a deployment happened) from authorization evidence (it was properly reviewed before it happened), which is exactly why pairing platform activity records with Git-based approval workflows matters more than the logs alone.
• ISO 27001 is a management system standard first and a set of technical controls second. The core of an ISO 27001 certification is a risk-driven Information Security Management System: risk assessment, treatment plans, management review cycles, and a Statement of Applicability. The technical controls a guardrail architecture satisfies, access control, cryptography, logging, sit under Annex A and support the ISMS; they don't replace the governance work the standard actually requires.
• GDPR doesn't mandate that EU personal data physically remain inside the EU, that's a common misreading. What it requires is a lawful basis for processing, data minimization, honoring data subject rights, and maintaining accurate records of processing activity, with Chapter V governing any transfer outside the EEA through mechanisms like Standard Contractual Clauses or an adequacy decision. Region selection at the project level supports GDPR's Article 32 technical safeguard requirement and simplifies cross-border transfer risk assessments, but it's a supporting mechanism, not the primary compliance requirement.
• PCI DSS, where relevant, centers on isolating the cardholder data environment from everything else, strong cryptography, multi-factor authentication for all access to that environment, and continuous vulnerability management, not primarily on backup procedures. A guardrail architecture supports scope reduction and consistent access control, but PCI DSS compliance still requires deliberate cardholder data environment scoping specific to the workload.
• DORA, the EU's Digital Operational Resilience Act, distinct from the DevOps research report of the same name, has applied since 17 January 2025. It covers financial entities and their ICT providers across five pillars: risk management, incident reporting, operational resilience testing, third-party risk management, and information sharing. Direct EU-level oversight applies to ICT third-party providers that have been formally designated as critical, not to every technology provider a financial entity uses. For everyone else the obligations arrive indirectly, through the contractual and third-party risk requirements the financial entity itself has to satisfy. The guardrail architecture supports the risk management and testing pillars specifically; it isn't a complete DORA compliance program on its own.

The pattern across all five: they overlap enough at the infrastructure layer that one consistent set of controls does real work for each of them, but they diverge in what they weight, and each has specific requirements a guardrail layer alone does not satisfy. The architecture removes the infrastructure-level manual work. The judgment calls, scope, risk assessment, and lawful basis remain the compliance function's job.

Getting there without a rebuild

Key takeaway: Building this architecture doesn't require re-platforming every existing service. It requires establishing the guardrail layer once and onboarding new work to it from day one, migrating existing services opportunistically.

The transition that stalls most compliance architecture efforts is the assumption that every existing service needs to move at once. It doesn't. New projects adopt the guardrail layer from their first commit, which stops compliance debt from accumulating further. Existing services migrate when they're actively being worked on, a feature cycle, a dependency upgrade, a security remediation, rather than in a dedicated compliance migration sprint.

The sequencing that works best starts with access and identity, since access is usually where drift from policy is widest in a fragmented environment, and where the evidence is hardest to reassemble after the fact. Encryption and logging follow naturally, since they're largely platform defaults rather than per-project configuration work. Region selection and backup policy come last, since they're the most workload-specific and benefit from being tuned once the foundational layer is already in place.

Done in this order, services move onto a consistent guardrail architecture as they come up for work, without a single forced cutover. Some will not fit cleanly. Workloads with unusual data-handling, networking, or certification requirements need more planning, additional integration, or a documented exception path, and it is better to identify those at the start than to discover them mid-migration.

Review your regulated delivery architecture with Upsun

Frequently asked questions (FAQ)

Does this architecture require abandoning our existing tooling and services?  
No. The guardrail layer governs access, encryption, activity records, region selection, and backups at the platform level. It doesn't require rewriting application code or replacing the databases, frameworks, or services a team has already chosen. Migration is about bringing existing projects under the guardrail layer, not rebuilding them.

How do we handle a framework this reference architecture doesn't explicitly cover?  
The five guardrails, access, encryption, activity records, region selection, and backup, map to evidence most compliance frameworks request in some form. Start by identifying which of the five your specific framework weights most heavily, and confirm the guardrail layer produces evidence in the format your auditor or regulator expects. For frameworks with additional scope-specific requirements, like PCI DSS's cardholder data environment isolation or DORA's resilience testing pillar, treat the guardrail layer as the foundation you build that additional work on top of, not a substitute for it.

What's the difference between this and just hiring more compliance staff?  
Compliance staff still make the judgment calls: interpreting scope, managing exceptions, conducting risk assessments, handling the specific attestations a framework requires. What this architecture removes is the manual evidence-gathering work underneath those judgment calls, the week of pulling logs from scattered systems before every audit. It makes compliance staff more effective, not unnecessary.

Does standardizing the guardrail layer slow down teams that are already moving fast? 
Generally not, since the guardrails, access control, encryption, and activity records, are things well-run teams are already trying to do consistently. What changes is that these become platform defaults instead of per-team implementation work, which typically speeds teams up rather than slowing them down.

What should an IT leader check first before adopting this model?  
Start with access and identity: can you currently name, for every environment, who has access and why, and can you prove that access changes went through proper authorization rather than just showing that they happened. If either answer takes more than a few minutes to produce, or requires checking multiple systems, that's the gap this reference architecture is built to close first.