Stop assembling audit evidence by hand: generate it on every deploy

Somewhere in every compliance program is a person who spends the week before an audit pulling logs out of several different systems, reconstructing who had access to what, and hoping the screenshots match what the auditor actually asks for. None of this work makes the system more secure. It just makes the existing security visible to someone who's checking.

That gap, between the controls that are actually in place and the evidence that proves it, is where most audit prep time goes. Closing it isn't a documentation problem. It's a question of where the evidence gets generated in the first place.

Why audit evidence usually means manual reconstruction

Key takeaway: Most compliance evidence exists somewhere in your systems already. The work isn't creating it, it's finding it, formatting it, and making sure it actually matches what happened.

Access logs live in one tool. Deployment history lives in your CI system. Configuration changes might be in Git, might be in a console someone clicked through, might be in a Slack thread where someone approved an exception three months ago. None of this is missing information. It's scattered information, and pulling it together into something an auditor can actually review is a manual, repeatable, entirely avoidable task that someone re-does every single audit cycle.

The predictable failure mode isn't fraud or negligence. It's drift. A control that was correctly configured in January gets adjusted in March for a one-off exception, and nobody updates the record that says the control is still enforced. By the time the audit rolls around, the evidence someone assembles is a snapshot of what people remember being true, not a record of what was actually true the whole time.

What changes when compliance is a property of the platform, not a step in the process

Key takeaway: Deploying on infrastructure that's already certified for major frameworks means the foundational controls aren't something you configure per project. They're already there, though application-level compliance still sits with your team.

Upsun Cloud is certified to ISO/IEC 27001:2022, holds an annual SOC 2 Type 2 report covering security, availability and privacy, and is a PCI DSS Level 1 service provider. HIPAA workloads are supported under a Business Associate Agreement's US-4 region. That matters beyond the certificate itself. 

According to IBM's 2026 Cost of a Data Breach Report, the global average cost of a breach has climbed to a record $4.99 million, up 12% year over year. Healthcare remains the costliest industry at $6.64 million per breach, down from $7.42 million the year before. Certification on infrastructure that's already built to these frameworks isn't a compliance checkbox. It's one less layer your team has to build, operate, and evidence on its own.

This is a shared responsibility model, and it's worth being precise about the split. The project inherits the underlying platform's certified posture for foundational infrastructure controls: physical security, OS patching, transit encryption, baseline audit logging. Your team remains responsible for what sits on top of that: secure application code, user authorization logic, API authentication, and the security of your own dependencies. Instead of a team assembling its own case for baseline infrastructure controls from scratch, that foundational layer is already satisfied. What still requires your team's judgment is everything specific to your application.

Where the audit evidence actually comes from

Key takeaway: Every deployment, code push, and configuration change is logged automatically as part of normal operation, not as a separate compliance-tracking exercise, though the strongest evidence pairs that log with your existing approval workflow.

This is the part that actually saves the hours someone currently spends the week before an audit. On Upsun Cloud, every deployment, code push, and configuration change is logged automatically as it happens. That's not a compliance feature bolted on top of the platform, it's the platform doing what it does anyway: recording what changed, when, and who changed it.

The practical effect is that the certifications, responsibility matrices and audit reports an auditor asks for are available from the Trust Center or on request, rather than assembled across multiple systems over weeks. The evidence isn't reconstructed after the fact from memory and scattered logs. It's a continuous record that already exists, because the platform was tracking it the whole time. When an auditor asks for a record of every configuration change to an environment over a given period, that record is retrievable through the API and CLI rather than reconstructed. Expired activities are pruned from the project activity log over time, so teams that need multi-year evidence should forward logs to their own retention store. 

This matters more every year: IBM's 2026 research found that 68% of breached organizations had no AI governance policy in place or were still developing one.

Worth being precise about what this replaces and what it doesn't: platform logs prove what changed, when, and by whom. They don't by themselves prove a change was approved before it happened. Pairing automatic deployment logs with your existing Git-based review process, where a pull request needs a separate approver before it merges, closes that gap: the log and the approval trail together are what auditors are actually looking for when they ask about change management, not the log alone.

Backups as compliance evidence, not just disaster recovery

Key takeaway: A defensible compliance posture needs to prove data protection continuously, and prove it can actually be restored, not just describe a backup policy on paper.

Backup and recovery capability is a control that most frameworks, SOC 2 and PCI DSS included, expect an organization to demonstrate, not just claim, and demonstrating it means more than showing a backup ran. Auditors under SOC 2's availability criteria expect evidence that recovery procedures have actually been tested, not just that a backup job completed on schedule. 

IBM's 2026 report reinforces why this matters: only 37% of breached organizations reported encrypting sensitive data both at rest and in transit, and just 34% had visibility into their cryptographic assets. Foundational hygiene, backups included, is exactly where most organizations are still exposed.

Upsun Cloud runs one automated backup a day of production environments by default, retained for two days. Both the interval and the number of retained backups are configurable per environment type, so the schedule can match what your specific compliance obligation requires rather than staying on the default. 

Because the backup process is automatic and consistent, the evidence that it happened, and happened on schedule, is a byproduct of the platform running normally, not a manual task someone has to remember and log separately. Restoration testing itself, proving a backup can actually be recovered, is worth building into your own review cadence rather than assuming it's covered by the backup running.

This is a small example of a bigger pattern: a control that's automated produces its own evidence. A control that depends on someone remembering to run a script produces evidence only when someone also remembers to document that they ran it.

What this means for release velocity

Key takeaway: When compliance evidence is continuous rather than reconstructed, releases stop waiting on a manual sign-off process that exists because nobody trusted the evidence to already be there.

The reason compliance requirements slow down releases usually isn't the requirement itself. It's the manual verification step that exists because the evidence isn't readily available. A release gets held for a compliance review because someone needs time to confirm the right access controls are in place, the right logging is happening, the right approvals were captured. If that evidence already exists continuously, and if approval trails are already linked to the deployment record, the review isn't a research task, it's a lookup.

This doesn't mean removing the review. It means removing the week of evidence-gathering that currently has to happen before the review can start. The compliance function still checks the box, still owns the judgment calls around scope, exceptions, and risk. It just isn't the one assembling the sources anymore.

• Review the shared responsibility model and certification scope in the Trust Center
• Estimate your platform cost on the pricing calculator

Frequently asked questions (FAQ)

Does this replace the need for a compliance team? 
No. Frameworks like SOC 2 and PCI DSS still require human judgment: interpreting scope, defining policy, managing exceptions, and making the actual attestations. What changes is the evidence-gathering work underneath those decisions. A compliance team spends less time reconstructing what happened and more time on the judgment calls that actually require their expertise.

How does this work across multiple environments or regions? 
Compliance controls that live at the platform layer apply consistently regardless of which region or provider a workload runs on. You can deploy on AWS, Azure, Google Cloud, IBM Cloud, or OVHcloud in specific regions to meet data residency requirements, though certification scope varies by region and provider. Some certifications are region-specific: HIPAA and TX-RAMP workloads, for example, run specifically on Upsun Cloud's US-4 region, so region selection should account for which certifications a given workload actually needs.

What happens during an actual audit with this model? 
Auditors can be given up-to-date compliance documentation, security policies, and audit reports from the Trust Center or on request, rather than a document your team assembled specifically for this review. Logs of deployments, code pushes, and configuration changes are available on demand, which shortens the evidence-gathering phase compared to reconstructing the same record by hand. Auditors will still expect these logs to connect to your own approval and change-management workflow, not stand in for it.

Is the backup schedule the same for every environment? 
No, it's configurable. Production environments can run a different backup schedule than staging or development environments, and the schedule can be adjusted to match the recovery point objective your specific compliance framework or internal policy requires. Restoration testing, confirming a backup can actually be recovered, is a practice worth building on top of the schedule itself.

Does automated compliance mean less control over our specific policies? 
No. The baseline controls that come from platform-level certification (encryption, access management, patching) are the floor, not the ceiling. Teams still define their own access policies, approval workflows, and exception handling on top of that baseline, and still own compliance for anything at the application layer: your own code, your authorization logic, your third-party dependencies. What changes is that the foundational infrastructure layer doesn't need to be built and proven separately by every team on every project.