Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Technology / AI SaaS |
| Cloud Environment | AWS (4 accounts), EKS clusters, RDS databases |
| Team Size | ~150 users across Engineering, DevOps, and Customer Success |
| Previous Audit Sources | Jira tickets, StackStorm execution logs, AWS CloudTrail, calendar entries |
| Compliance Requirements | SOC 2 (needed for procurement), ISO (in place) |
| Audit Gap | No unified trail connecting request → approval → grant → action → revoke |
| Primary Pain Points | Ops overhead, maintenance, lack of integrated workflow, missing audit logs |
| Cloudanix Scope | Cloud Console JIT, Database JIT, Kubernetes JIT — unified audit |
The Situation: Four Log Systems, Zero Complete Picture
When this AI SaaS company’s security team was asked “who has access to production, and who approved it?” — the answer required assembling evidence from four independent systems:
- Jira: The access request (who asked, what they wanted, their stated reason).
- StackStorm: The execution log (whether automation provisioned the access, and when).
- AWS CloudTrail: The IAM event (the actual permission change in AWS).
- Calendar: The revocation reminder (when access was supposed to end).
Each system captured a fragment of the access lifecycle. None captured the complete picture. And critically, no system connected these fragments automatically — correlating a Jira ticket from Tuesday with a StackStorm execution at 10:15 AM with a CloudTrail event at 10:17 AM with a calendar entry for Thursday at 10:15 AM required manual effort.
The team listed this explicitly as one of their primary challenges: Missing Audit Logs. Not that logs didn’t exist — they existed in four places. But the coherent story of “this person requested this access, it was approved by this person, it was granted at this time, these actions were taken during the session, and it was revoked at this time” was nowhere.
For SOC 2 certification — which the company needed for procurement conversations with enterprise customers — this gap was a direct compliance risk. SOC 2 requires demonstrating that access is governed, time-bound, approved, and auditable. The team could demonstrate each piece individually from different systems, but couldn’t produce a single, coherent evidence package.
The Core Challenge
Access governance evidence was scattered across Jira, StackStorm, CloudTrail, and calendar entries. No single timeline connected request to approval to grant to action to revocation. For compliance (SOC 2) and for incident investigation, this fragmentation meant either expensive manual correlation or incomplete evidence.
Where the Gaps Were
Jira: Records the Intent, Not the Outcome
Jira captured the access request: who asked, what they wanted, for how long, and why. This is valuable context. But Jira couldn’t confirm:
- Was the access actually granted? (The ticket might be marked “Done” while the IAM change failed.)
- When was it granted? (The ticket resolution time doesn’t equal the IAM change time.)
- Was it revoked? (Jira has no mechanism to confirm revocation occurred.)
- What happened during the access window? (Jira doesn’t see AWS API calls.)
A Jira ticket is evidence of intent. It’s not evidence of governance.
StackStorm: Records the Automation, Not the Lifecycle
StackStorm logged when it executed an access provisioning action: “Rule X triggered, action Y executed against account Z.” This confirmed the mechanical act of granting access. But StackStorm couldn’t record:
- Who approved the request (StackStorm auto-executed based on ticket metadata, bypassing human review for certain patterns).
- What the user did with the access once granted.
- Whether revocation occurred (StackStorm didn’t handle revocation — that was calendar-based).
- The business justification beyond what StackStorm could parse from ticket fields.
StackStorm execution logs are evidence of automation. They’re not evidence of governed access.
CloudTrail: Records the Action, Not the Authorization
AWS CloudTrail captured every IAM API call: AssignUserToGroup, CreateAccountAssignment, DeleteAccountAssignment. This is the ground truth of what happened in AWS. But CloudTrail doesn’t record:
- Who approved the access change (CloudTrail shows which IAM principal made the API call — either StackStorm’s service role or the DevOps lead’s session, not the approval decision chain).
- Why the access was granted (no business context in CloudTrail events).
- When the access should expire (CloudTrail doesn’t know about intended durations).
- The correlation between the CloudTrail event and the originating request.
CloudTrail is evidence of API activity. It’s not evidence of governed access lifecycle.
Calendar: Records Nothing Enforceable
Calendar entries for revocation recorded the intention to revoke access at a future time. They didn’t record:
- Whether revocation actually occurred (no feedback loop from IAM to the calendar).
- Whether it occurred on time (a calendar reminder at 2 PM doesn’t confirm IAM removal at 2 PM).
- Who performed the revocation (if it happened at all).
- What happened between grant and revocation.
Calendar entries are evidence of planning. They’re not evidence of control.
The Compliance Impact: SOC 2 Requires What They Couldn’t Produce
SOC 2 Trust Services Criteria for access control (CC6.1, CC6.2, CC6.3) require:
- Logical access provisioning and deprovisioning is performed through formal processes.
- Access is reviewed and modifications are made based on changes in job responsibilities.
- Access requests are documented with approvals, and access is revoked when no longer needed.
The team could point to Jira tickets (requests), StackStorm logs (provisioning), and CloudTrail events (changes). But producing a coherent evidence package that an auditor could follow — request through lifecycle to revocation, for a sample of access events — required hours of manual correlation per sample. For SOC 2 readiness, this was unsustainable.
The Cloudanix Solution: One Timeline Per Access Event
Cloudanix JIT produces a single, complete audit record for every access event — from request to revocation — with no manual correlation required.
Anatomy of a JIT Audit Record
Every JIT access event generates one unified timeline:
Access Event: jit-cloud-8a3f4c21
─────────────────────────────────────────────
[2026-03-12 09:14:32] REQUEST
Requester: engineer@company.com
Resource: AWS Account: Production-1
Role: Developers_Editor
Duration: 2 hours
Reason: "Investigating INC-2341 — payment failures"
[2026-03-12 09:14:33] APPROVAL
Approver: devops-lead@company.com
Method: Slack (one-click approve)
Response time: 47 seconds
[2026-03-12 09:14:34] GRANT
Action: Permission set Developers_Editor assigned
Account: Production-1 (111122223333)
User: engineer@company.com (IDC user ID: u-abc123)
Valid until: 2026-03-12 11:14:34
[2026-03-12 09:15:01] SESSION START
User signed in via SSO portal
Session ID: sess-7d4f...
[2026-03-12 09:15:44] ACTION: ec2:DescribeInstances
[2026-03-12 09:18:12] ACTION: logs:GetLogEvents (log group: /ecs/payments)
[2026-03-12 09:23:07] ACTION: ecs:DescribeServices
[2026-03-12 09:31:45] ACTION: ecs:UpdateService (restart)
[2026-03-12 11:14:34] REVOKE
Trigger: Duration expired (automatic)
Action: Permission set Developers_Editor unassigned
Verified: Assignment removed from IDC
─────────────────────────────────────────────
Total session: 1h 59m 33s
Actions during session: 4 API calls recorded
Revocation: Automatic, on-time, verifiedEvery element that SOC 2 requires — the request, the approval, the grant, the actions taken, and the revocation — exists in one timeline, for one access event, queryable by user, by date range, by account, by role.
What Auditors See: Evidence Packages
For SOC 2 (or ISO 27001) evidence requests, the security team can produce:
- Sample of access events in Q1: Pull 25 JIT records from January–March. Each shows the full lifecycle.
- All production access for User X: Query by user, filter by production accounts. Complete history with approvals and durations.
- Access during incident INC-2341: Query by reason field. See exactly who was granted what access during the incident, what they did, and when it was revoked.
- Revocation compliance: Demonstrate that 100% of access grants were revoked (either automatically at expiry, or early by request). Zero standing access persisted beyond approved windows.
No manual correlation. No assembling evidence from four systems. No hoping that Jira timestamps align with CloudTrail timestamps.
Database JIT Audit: Query-Level Attribution
For Database JIT sessions, the audit trail extends to the query level:
Access Event: jit-db-3c9a1f72
─────────────────────────────────────────────
[REQUEST] developer@company.com → production-api DB, read-only, 1h
[APPROVAL] auto-approved (dev-readonly-policy)
[GRANT] IAM-authenticated credentials issued
[QUERY] SELECT * FROM orders WHERE date > '2026-03-01'
[QUERY] SELECT COUNT(*) FROM users WHERE status='active'
[REVOKE] Automatic at 1h expiry, credentials invalidated
─────────────────────────────────────────────This answers the question traditional database audit logs can’t: which human ran which query. Not “vault-token-abc123 ran a SELECT” — but “developer@company.com ran SELECT * FROM orders.”
Kubernetes JIT Audit: Command-Level Recording
For Kubernetes JIT sessions, every kubectl command is recorded:
Access Event: jit-k8s-5d7c2e89
─────────────────────────────────────────────
[REQUEST] sre@company.com → eks-prod, edit, payments namespace, 30m
[APPROVAL] auto-approved (sre-staging-edit-policy)
[GRANT] Ephemeral kubeconfig minted, tunnel opened
[COMMAND] kubectl get pods -n payments
[COMMAND] kubectl logs payments-7d6c9-abc1 --tail=50
[COMMAND] kubectl rollout restart deploy/payments -n payments
[REVOKE] Session expired, kubeconfig invalidated, tunnel closed
─────────────────────────────────────────────
Session recording: available for replay
Export and Integration
Audit data isn’t locked in Cloudanix:
- S3 export: All audit records land in the customer’s own S3 bucket. The customer owns the data.
- SIEM integration: Send audit events to Splunk, Elastic, or SumoLogic for correlation with other security data.
- Compliance reports: Generate time-bounded reports (quarterly, monthly) filtered by account, team, or access type.
- Signed URLs: Share specific access event records with auditors via time-limited links that expire.
Platform Impact
| Audit Capability | Before | After |
|---|---|---|
| Systems to correlate per access event | 4 (Jira + StackStorm + CloudTrail + Calendar) | 1 (Cloudanix JIT timeline) |
| Time to produce evidence for 1 access event | 15–30 minutes (manual correlation) | Instant (single query) |
| Complete lifecycle coverage | Partial (gaps between systems) | Full (request → revoke in one record) |
| Revocation verification | None (calendar ≠ confirmation) | Verified removal in IAM Identity Center |
| Identity attribution | Fragmented (different IDs in different systems) | Single identity across all records |
| Query-level database audit | Not possible (Vault username ≠ human) | Full (every query, identity-stamped) |
| K8s command audit | Not possible (shared cluster-admin) | Full (every kubectl, identity-stamped) |
| SOC 2 evidence production time | Days per audit cycle | Hours per audit cycle |
Why Scattered Audit Trails Are a Compliance Risk
The issue isn’t that data doesn’t exist. AWS CloudTrail logs every API call. Jira preserves every ticket. Vault logs every credential issuance. The issue is that no single system tells the governance story:
“This person was authorized to have this access, for this reason, approved by this person, for this duration, and this is what they did with it.”
Without that story in one place, compliance becomes an exercise in retrospective correlation — assembling the narrative after the fact by matching timestamps across systems and hoping the alignment is unambiguous. It usually isn’t.
Auditors don’t want to see four systems and a spreadsheet that correlates them. They want one timeline per access event that demonstrates governance. Cloudanix JIT produces that timeline automatically, for every access event, across cloud consoles, databases, and Kubernetes clusters.
Producing Fragmented Audit Evidence Today?
If your access audit trail lives across Jira, Slack, CloudTrail, Vault logs, and calendar entries — and producing SOC 2 evidence means hours of manual correlation per sample — Cloudanix JIT generates one complete timeline per access event, automatically, with no assembly required. Request, approval, grant, actions, revocation — all in one record, all identity-stamped.
Book a Free Assessment to see what your access audit trail looks like when every event is captured in one timeline.
