Recently worked with Rhymetec and BD Emerson on SOC 2 engagements and both of the vCISOs were acting like they’ve never been in an audit before or were confused about controls from the type 1? I did some digging and some of the “vCISO”s have 2 years of experience? Who is actually paying for this shit?
Most SOCs have decent detection and decent remediation. What I've watched break consistently is the handoff between them.
A detection fires. An analyst triages. An action item gets generated. The action item lands in Jira, ServiceNow, or, worst case, a Slack thread. The detection team considers the work done at the moment they hand it off. The remediation owner considers the work started at the moment they pick it up. The gap between those two moments is where SLA breaches accumulate, evidence gets lost, and findings show up in the next audit as "remediation not consistently completed."
I'm now at Process Street working on this category specifically, but the pattern I'm describing predates my move and isn't tool-specific. Calling it out for context so you can weight the recommendation accordingly.
What the failure mode looks like in practice. Detection team marks an alert "remediated" because they routed it to ServiceNow, then six months later an auditor pulls a sample and finds 12% of remediations were never actually performed. Remediation owner gets a ticket without context of why it matters, prioritizes it as routine, original SLA was 24 hours and actual time to close was 18 days. Evidence of remediation (config diff, log entry, screenshot, ticket comment) lives in five different systems, compiling it for audit takes 40 hours per quarter. The same vulnerability class recurs because nobody closes the loop back to detection rules.
The structural insight that keeps coming up. The handoff isn't a ticketing problem, it's a workflow execution problem. Ticketing tools (Jira, ServiceNow) are good at tracking discrete tasks but not at modeling "this can't be marked done until that's signed off with specific evidence at the step." That gating layer is its own category. SOAR platforms (Splunk SOAR, Cortex XSOAR, Tines) handle the automation side but most don't model the human-in-the-loop approvals well for control-type-specific evidence requirements.
What I've watched work, regardless of which tool. The handoff has to be a single workflow with both teams as stakeholders, not two systems passing a ticket. The detection team's "done" condition is the remediation team's "received" event, with the receipt requiring confirmation. The remediation owner can't mark "done" without attaching the specific evidence required by the control type (config, log line, attestation). The auditor's evidence package is generated from the workflow run record, not assembled afterwards.
Tools matter less than this structural choice. We've watched it work in ServiceNow with heavy customization, Jira with workflow plugins, SOAR platforms for the automation half, and dedicated workflow execution platforms (Process Street, Tallyfy, similar) for the procedural half. What hasn't worked is leaving the handoff to "the team will follow the SOP we wrote."
Curious what others are seeing here. Are most cybersecurity orgs still treating detection and remediation as separate systems with manual handoff, or are people consolidating into single workflows? And for the orgs doing single workflows, what's the consolidation pattern that's holding up?
Start documenting processes much earlier than you think you need to. Most teams focus on security tools first, but SOC 2 audits usually become difficult because everyday operational processes are inconsistent or undocumented.
Things like access reviews, employee onboarding/offboarding, incident handling, infrastructure changes, and vendor approvals need to be repeatable and traceable. If those workflows are already part of how the team operates, SOC 2 becomes far less stressful.
Also, avoid treating compliance as a one time audit project. It works much better when engineering, DevOps, and operations build lightweight compliance habits into daily workflows from the start.
How did your team prepare for SOC 2 without creating too much operational overhead?
Just finished ISO 27001 certification (EU, ~35 employees) using a large “all-in-one” GRC platform and a well-known auditor. Sharing a quick lesson learned:
We trusted the GRC tool too much.
During the audit we had to adjust evidence (in agreement with the auditor). None of these were critical alone, but together they nearly became a non-conformity:
- Scope template incorrectly included the company name by default.
- Scope lacked clear climate-related references.
- SoA template missed basics (company name, applicability yes/no, proper control descriptions).
- Built-in risk scenarios were far too high-level.
- Risk management policy template lacked risk acceptance criteria.
- Third-party management template didn’t clearly address vendor lock-in prevention.
- Templates were overly formal and outdated (e.g. ISMS councils SMBs don’t have, DVDs as asset examples).
- Cloud integrations (AWS, Microsoft, etc.) were great, but auto-generated scan evidence was hard for auditors to interpret, requiring manual explanations.
Individually manageable. Combined, almost a finding. Also learned that auditors interpret some things differently, after disccusion the above with the grc-platform provider.
Posting this as a heads-up for others that are planning ISO 27001 certification with a GRC platform.
TL;DR:
GRC tools help a lot, but their templates are not “audit-safe by default”. Review scope, SoA, risk models, and auto-generated evidence carefully — don’t follow templates blindly.
Interesting paper on a fairly under-discussed issue in DNS: what happens to expired or repurposed domain names that remain embedded in DNS dependencies across systems. The core finding is that these “orphaned” or changed domains can persist in resolution paths and integrations long after their original context is gone, creating real security and reliability implications.
My take: this becomes even more relevant in modern AI systems, where agents, tools, plugins, and third-party APIs are rapidly stitched together. In that environment, domain names and DNS-level dependencies can quietly extend the AI supply chain attack surface in ways that are easy to overlook.
And regretting it.
Their tool is soo frustrating. They made a new experience which is much worse than the older experience.
And now they are also moving to a model where they will make you pay for each and every small service.
Had a discussion with my previous org's ciso, and they shared earlier drata had a lot of things to offer in their contract which is not present anymore.
Not sure if someone else has experienced this?
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:
for context, im in-house IT working with our MSP partner.
Currently were going for SOC 2 compliance, and were currently going to enforce DLP with purview.
This project is starting from the ground up. As in, none of the data in our sharepoint database has been tagged. We have some service accounts that also read data from there for quick summarization. There is some major problems were worried about:
-There is about 1.4 Million files on sharepoint currently, and we dont know how well purview will tag a file with a sensitivity label if it contains PII
-We have an additional software that sits over sharepoint (a DMS) that just basically sorts the files on sharepoint for easy organization and retrieval. Were worried the sensitvity labels might ruin access to the file
-my MSP partner warned me that he has seen sharepoint be unreliable at times, and said that right now sharepoint has been working pretty decently with the DMS till now. Any modification to the files might make sharepoint go haywire
-I wanted to also apply encryption but that again, might break the service account
Has anyone ever navigated this before? what would be the best solution here?
We thought our access review workflow was airtight. Quarterly manager reviews, sign-offs in our task system, evidence captured. Then our auditor found a gap nobody noticed for 8 months.
The gap: when an employee changed roles within the company (engineering to product, IC to manager, etc.), their old role-based access wasn't being revoked. The access review process only checked "does this person still work here" and "do they still need their current access." It never asked "should they still have access from their previous role."
By the time our auditor caught it during sample testing, three employees had access permissions from old roles they hadn't held in over a year. Auditor flagged it as a finding.
The fix was process, not tool. Added a step in our role-change workflow (handled by HR) that triggers an access revocation review with IT before the role change is finalized. Now every internal transfer fires an access cleanup task.
Sharing because I keep meeting teams whose access review process has this same gap and they don't realize it. Internal transfers fall between the cracks of "still employed" and "current role access" if you don't specifically design for it.
Anyone else hit this in their first or second audit?
As the title says, recently my position at my company changed and I was tasked to take care of few certifications. First one was training for SOC2 etc so we can file for it.
My question is what am I expecting? How to prepare for it and is there a good career in this field?
🙃❤️
Hi guys,
I’m a software architect and I've recently started working more on the compliance side. Coming from a dev background, I expected to see people using dedicated platforms to manage everything, but I’ve noticed that most of the senior people I work with still do almost everything in Excel.
I’ve looked at tools like Vanta, and they seem useful at first glance, but the experienced colleagues I talk to still seem to prefer their spreadsheets.
I’m curious to hear from people who have been doing this for a while—why is that? Is it just that the tools are too rigid for real-world work, or is there another reason Excel is still the standard?
I’m trying to understand if these platforms actually make things easier or if they just get in the way.
Thanks for your inputs
Anyone know what the rules are on this? I’m currently in middle of a SOC assessment but I know my client will soon be hiring and I really want to work with them, and they seem keen on me as well.
However I have a feeling there are some rules around this? If I applied, do I need to tell my current employer I have done so?
I’m currently doing SOC 2 audits at an execution level but I’m transitioning into managing audit engagements and want to build a much deeper understanding of the framework.
My main question is: how did you actually build your competence?
How did you get a solid grasp of the AICPA standards, Trust Service Criteria, and the overall SOC 2 audit methodology? Any specific resources like books, courses, certifications, that you can recommend to build audit mindset and compliance knowledge.
Also, how did you go about getting a grip on technical aspects that addresses each control.