Right now the most important thing is verifiability & depth, rather than just compliance automation-because it does exist, everywhere.

Here's what I did from learning this:

-> Created an open-source AWS Evidence Scanner & Control Mapper for lean, pre-series A AWS-Native teams thinking about SOC 2 Type l or are undergoing SOC 2 Type l audit. Collects across 15+ AWS Services to 12 critical controls in the trust-service criteria.

Why open-source? Accessibility for people who might have their hands tied choosing between expensive GRC tools. Its also used as a trust-mechanism. Code is right there. A CEO or auditor can read exactly what API calls we make before giving us the role ARN.

-> I included a paid report embedded within the tool (open-core model). Users have the option to pay for the report in which every finding traces back to the API call that produced it. SHA-256 hashed (at a fraction of the cost of bigger legacy platforms). With remediation steps & a compliance-copilot to help with other parts of the Type l process beyond evidence collection (like policy writing, risk assessment, etc).

Why paid report? The best way to make the auditors job as easy as possible is to give them a verifiable package where the evidence is right there in front of them, timestamped so they can see what happened, when (rooted in AWS APIs). No black-box, no way to fake it. Saving weeks of back & forth between auditors and clients, with the click of a few buttons.

An auditor can re-run the same API call, hash the response themselves, and verify it matches what's in the report.

Value: 30 seconds to deploy. 5 mins to run the scan & evidence is collected & mapped. Paid report includes verifiable evidence companies can send to their auditor. Paid features include a co-pilot to help with audit-readiness beyond just evidence collection.

-> Understand Limitations.

I understand the scope of this product is pretty limited in part because its also very new. I'm not going to claim it solves all of compliance, because it doesn't. It makes a very time-consuming part of the process very accessible to be automated & gives an auditor a report they can rely on.

What now? Anyone who's gone through, thinking about or is in the middle of SOC 2, would love your reaction to the output, even if it's critical. Also looking for early testers/users.

repo here: https://github.com/adog0822/AWS-Evidence-Layer

try it here: https://loxeai.com

Comments URL: https://news.ycombinator.com/item?id=48164906

Points: 2

# Comments: 0

What's most important for you would just being able to prove to your customers that you do what you say you do.

The core issue isn't SOC 2, it's verifiability. Your customers want to know that what you claim about your security posture is actually true, not just documented.

I've actually been deeply exploring the compliance space lately and a few days ago I built an open-core pre-audit readiness layer. Every finding traces back to the raw AWS API call that produced it, SHA-256 hashed. An auditor or skeptical customer can verify it themselves without taking your word for it.

Its more SOC 2-esque, & its pre-audit readiness not a certification, but it does the job of proving you are trustworthy.

repo if relevant: https://github.com/adog0822/AWS-Evidence-Layer

(I built this, disclosing upfront)

Comments URL: https://news.ycombinator.com/item?id=48070885

Points: 1

# Comments: 0