u/Prior-Interview-6864

Going through SOC 2 Type II and stuck on a specific problem I can't find a clean answer to.

Vanta handles the technical side fine. MFA enforced in Okta, encryption on S3, branch protection on GitHub all automated, all green.

The problem is controls where a human has to actually do the work. Three examples I'm struggling with:

Quarterly access review (CC6.2): My engineering lead spent two hours in AWS IAM and Okta, reviewed all accounts, removed two stale ones, created Jira tickets for the removals. What does your auditor actually want to see here? A spreadsheet? A Jira export? A written summary? How do you prove the review happened and wasn't just a checkbox?

Incident response (CC7.2) We had a production outage in May. Team responded within SLA, ran a post-mortem. But reconstructing the timeline for an auditor means pulling from PagerDuty, Slack threads, and a doc written two days later. Is that actually acceptable or do auditors push back on reconstructed timelines?

Vendor risk assessment (CC9.2) We review critical vendors annually. Right now the evidence is a folder with a completed questionnaire PDF and an email thread. That feels thin.

Questions for anyone who's been through a Type II:

• What format does your auditor actually accept for access review evidence?
• Has anyone had an auditor reject reconstructed incident timelines?
• What's the weakest evidence you've seen an auditor actually accept for a human performed control?

I lead a dev team of 8 engineers, no PM in our company so i'm the one doing it. we prefer to keep meetings minimal.

in our standups we go through each persons items and roughly the first half is just discovery. someone mentions theyre blocked, we spent around 30-40 minutes a day just to understand the overall picture and what problems have come up so everyone is on the same page.

the data is all in jira but i still have to go through ticket by ticket to piece together whats actually at risk. theres no synthesized view.

what i want is to know the blockers before the meeting starts, and ideally share that view with the whole team beforehand so everyone walks in already knowing the problem and can come with a solution. instead of everyone finding out at the same time in the meeting.

Also since the team is lean everyone in the team knows what part of the software the other owns and are very familiar with the overall architecture of everything, Thats why in most of our problems and blockers everyone discusses their opinion and having a list before hand with explanation i think would really help the team move faster with our standups.

has anyone cracked this without spending 30 mins on tickets the night before?

I've managed teams long enough to be uncomfortable with how we do "team visibility."

Activity scores based on mouse movement. Screenshots every 10 minutes. Timesheets nobody believes. Status meetings that exist only because the tools we already pay for don't actually tell us anything useful.

The thing that gets me is that the people doing the deepest, most valuable work, engineers debugging hard problems, designers thinking through layouts, sales reps actually on calls, usually score the worst on these tools. Meanwhile mouse jigglers exist for a reason.

So we're measuring the wrong thing, punishing the right people, and calling it productivity.

I rarely see managers talk about this honestly. Most of us just accept that the dashboard is broken and keep using it.

Genuine question for the managers, PMs and founders here:

• How do you actually know what your team did this week?
• Do your monitoring tools tell you anything you trust?
• Have you found a better way or are you also just living with it?

Not trying to start a flame war, just want to hear honest takes.
Thanks.