The week before SOC2 fieldwork, one of your senior engineers stops shipping. Instead, they are screenshotting IAM consoles, exporting deploy histories, and reconstructing who changed the autoscaling configuration in March and whether that person was allowed to. SOC2 Type II is not a point-in-time check; it covers an observation period of six to twelve months, which means the evidence has to exist for the whole window, and someone has to assemble it every single cycle. If that someone is a senior engineer, you are paying senior engineer rates for archaeology, quarter after quarter, forever.
There is a cheaper shape for this problem. If the platform your team deploys through stamps every sensitive operation with who did it, what role they held, what they did, and when, then evidence collection stops being a project and becomes a log export. The engineer hours come back, and so does something harder to price: the risk of an audit finding drops, because the evidence is generated as a side effect of normal operations rather than reconstructed from memory and screenshots. This post walks through how a Convox Rack, self-hosted in your own AWS, GCP, or Azure account, produces exactly that kind of audit-attributed record, and it is honest about what platform automation cannot cover.
Most teams treat SOC2 evidence as a documentation task: write the policy, then prove you followed it. The policy half genuinely is documentation. But the proof half is operational data, and operational data is only trustworthy if it was captured at the moment the operation happened, by the system that performed it. An auditor evaluating change management for a Type II report does not want a spreadsheet a lead engineer filled in the week before fieldwork. They want records that were emitted continuously across the observation period, that attribute each action to an authenticated identity, and that could not have been quietly edited after the fact.
That is a devops automation requirement, not a paperwork requirement. Manual evidence collection fails in a predictable way: the observation period is long, the people are busy, and the tooling underneath most deploy pipelines was never designed to answer "who, with what authority, did what, when" as a first-class question. So the answer gets reconstructed from git history, Slack threads, and cloud console screenshots, each of which an auditor can reasonably question. The reconstruction itself consumes days of senior time each cycle, and the arithmetic is easy to run for your own team: count the engineers involved in your last evidence request, multiply by the days each spent, and compare that against what those same people would have shipped instead. That number recurs every audit cycle for as long as you hold the report.
The common reflex is to conclude you need a platform team to build this instrumentation, or a GRC tool line item to paper over its absence. Neither follows. As we argued in platform engineering without a platform team, the capabilities a platform team would build, including consistent deploys, role-gated operations, and audit trails, can be adopted as a platform rather than staffed as a department. The evidence problem is a specific instance of that general claim: you do not need to build audit instrumentation if the platform you deploy through already emits it.
Strip the compliance language away and an auditor's evidence request for change management reduces to four fields per event: who acted, what authority they held, what they did, and when. Any devops automation tools you evaluate for audit readiness should be judged on whether they emit those four fields on every sensitive operation, attributed to a real authenticated identity rather than a shared service account.
Convox Racks make this concrete on the operations that touch spend and capacity, which are exactly the ones auditors probe for unauthorized change. From rack version 3.24.6 onward, every budget mutation emits an audit event whose actor field carries the authenticated user's email. When someone raises a spend cap from the Console or runs convox budget reset from the CLI, the resulting event says alice@example.com did it, not rack-password or a generic system identity. Events the rack generates on its own, such as a budget cap arming or firing automatically, carry actor = "system", so the record distinguishes human action from platform action without any interpretation on your part.
The detail that matters for anyone building a receiver or feeding a SIEM is that the actor value is normalized before it is stamped, with documented guarantees: invisible and non-printable characters are stripped, including the bidirectional-text override characters that could otherwise spoof how a value renders in an audit log; the value is capped at 256 characters; and a value that is empty after normalization becomes the literal string unknown. An ordinary email address passes through unchanged. The practical consequence is that your downstream tooling can trust the field without re-sanitizing it, which is the difference between an evidence pipeline you set up once and one that needs its own maintenance rotation.
Console operations get the same treatment. Changing an app's autoscale configuration through the Console, or through the equivalent CLI command, is recorded in the audit log with the acting user's email. A capacity change like this is a logged, attributed operation, not an anonymous knob turn:
$ convox services triggers enable web --min 1 --max 5 --cpu 70 -a my-appWhen your auditor asks who changed the scaling floor on the production web service in the third month of the observation period, the answer is a filtered log query with a name and a timestamp attached, not an interview.
Attribution answers who acted. Least privilege is the harder half: proving that people who should not have been able to perform an action actually could not. Most teams demonstrate this with screenshots of IAM policies and role assignments, which shows configuration at one moment in time and says nothing about whether the enforcement held across the observation period.
Convox splits sensitive operations across authorization tiers, and the split is enforced by the rack itself, not just hidden in a UI. Budget operations are the clearest example. Setting or raising a monthly cap, changing the at-cap action, and clearing a budget entirely all require the Admin role. Routine recovery, such as acknowledging a cap breach with convox budget reset or adjusting the alert threshold, requires only the read-write role. The design intent is directly auditable: an admin-set spend cap cannot be silently circumvented by a non-admin clearing the budget and re-creating it without the cap, because the clear operation itself is admin-gated.
| Operation | Required role |
|---|---|
Set or raise the monthly cap (--monthly-cap) |
Admin |
| Set the at-cap action or pricing adjustment | Admin |
Clear budget config (convox budget clear) |
Admin |
Reset with --force-clear-cooldown |
Admin |
Plain reset (convox budget reset) or alert threshold change |
Read-write |
What makes this evidence rather than just architecture is that the enforcement produces its own records. A non-admin caller attempting an admin-only operation receives a specific, documented rejection:
403 AppBudgetSet: admin role required to set budget cap
403 AppBudgetClear: admin role required to remove budget configA denied attempt with an explicit reason is exactly the kind of artifact that turns a least-privilege assertion into a demonstrated control. The role model underneath comes from Console RBAC, which applies to both the Console and the CLI under a zero-trust default: access not explicitly granted is denied. Rack-tier operations layer on a further gate, where only organization administrators can reveal sensitive values like the webhook signing key, while members see a masked value, and the server enforces that independently of the UI.
One enforcement detail worth surfacing to your auditor proactively: requests authenticated with the rack password rather than a Console identity pass the admin check automatically. If scripted flows in your environment use the rack password, scope it tightly and document who holds it, or move those flows to identity-based access. Knowing the boundary of a control is part of evidencing it, and it is better that you name it than that fieldwork finds it.
Evidence trapped inside the platform that generated it is only half useful. Auditors, and your own security reviews, want the trail in a system of record you control: a SIEM, a log archive, or at minimum an append-only channel your team monitors. Convox gives you two paths, and both are verifiable rather than trust-me.
The first is outbound webhooks. When a webhook_signing_key is configured on the rack, every outbound webhook carries a Convox-Signature header: an HMAC-SHA256 signature over the timestamp and raw body, keyed on the signing key. Your receiver recomputes the HMAC, compares in constant time, and rejects anything outside a five-minute timestamp window. That means the entry in your SIEM is not merely a claim that the rack sent an event; it is cryptographically attributable to your rack. The rack supports up to four active keys at once, so key rotation happens without a gap in verified delivery, and the documentation ships receiver verification code in Python, Go, Node, and shell that your team can paste rather than write.
The second path is the dispatch log itself. Every webhook dispatch writes a structured audit line to the api pod's stdout, which a SIEM collector or an engineer can pull directly:
$ kubectl logs -n convox-system deployment/api -c api | grep webhook_dispatchSuccessful dispatches log lines of the form audit_type=webhook_dispatch_succeeded url_host=hooks.example.com status=200, and failures log audit_type=webhook_dispatch_failed with the status. So even the delivery of your evidence stream is itself evidenced, which closes the loop an auditor will otherwise ask about: how do you know the events reached the system of record?
The honest caveat, straight from the documented behavior: the rack does not retry failed dispatches, and the signature scheme carries no nonce, so within the timestamp tolerance window a replayed payload verifies. Build your receiver to be idempotent, treat the dispatch-failed log lines as an alerting signal, and if you need replay protection, deduplicate on the timestamp and a body hash. None of this is exotic engineering, but it is engineering you should plan for rather than discover during fieldwork.
A platform that emits attributed, role-gated, signed events covers a specific slice of SOC2: the change management and access control evidence attached to how software reaches and runs in production. That slice happens to be the one that eats the most engineer hours, because it is the one where evidence must span the whole observation period and where reconstruction is hardest. But it is a slice, not the report.
You still need written policies, and a platform cannot write them. You still need HR controls: onboarding and offboarding procedures, background checks where your policy requires them, security awareness training with completion records. You still need vendor management, risk assessments, incident response documentation, and business continuity planning. If you use a compliance automation product to orchestrate those, the platform events described here feed it rather than replace it. The claim of this post is narrower and, we think, more defensible: the deploy-time and operations-time controls, which are the ones your senior engineers currently spend days proving by hand, can be proven by export instead.
There is a second-order benefit for the buyer worried about vendor lock in cloud decisions tend to create. Because a Rack is self-hosted in your own cloud account on standard Kubernetes, the audit trail lives in infrastructure you own. Your CloudTrail, your log retention, your SIEM. The evidence does not sit inside a vendor's SaaS where losing the subscription means losing the history. If Convox disappeared tomorrow, your cluster, your logs, and your collected evidence would all still be yours, which is itself an answer to the vendor-risk question every auditor asks about small platform vendors. Convox is compliance ready through this inherited-controls architecture; it is not itself SOC2 certified, and it does not need to be in scope for your data, because your data never leaves your account.
No, and they should not try. Compliance platforms orchestrate policies, HR controls, vendor reviews, and evidence workflows across your whole organization. Platform-level devops automation covers the change management and access control slice: attributed deploys, role-gated operations, and signed event streams. The right posture is to let the platform generate that operational evidence automatically and feed it into whatever GRC tooling manages the rest.
Budget mutations emit audit events with the authenticated user's email in the actor field from rack 3.24.6 onward, with documented normalization receivers can trust. Console actions such as autoscale trigger changes and budget configuration are audit-logged with the acting user's email. Denied privilege escalations return documented 403 messages, and webhook dispatches log structured success and failure lines a SIEM can ingest.
Each sensitive operation carries an actor field with the authenticated user's email, distinguished from system-generated events which carry a system actor. Because operations are role-gated by the rack itself, the log shows both that a named person acted and that they held the required role, and events shipped by webhook are HMAC-signed so the receiving system can verify they came from your rack.
It narrows it in your favor. A self-hosted Rack runs entirely inside your own AWS, GCP, or Azure account, so infrastructure controls are inherited from the cloud account you already govern, and your data never transits a platform vendor's environment. The audit trail lives in logs you own and retain on your terms, which simplifies the vendor-risk conversation with your auditor.
Here is a concrete next step that takes an afternoon, not a quarter. Pull your auditor's most recent evidence request list and mark every item that reduces to who did what, with what role, and when: deploy approvals, capacity changes, spend control changes, privilege enforcement. Those are the items a Rack emits automatically. Then evaluate the platform against that marked-up list, and weigh what a Rack costs against the senior engineer days your last evidence cycle consumed, using your own numbers.
Create a free account and pilot a Rack in a staging AWS account to see the audit events land in your own logs before the next observation period starts. For compliance-specific questions, including GovCloud and HIPAA workloads, talk to our team.
