We use one of the known compliance platforms for audits which also help set some level of automation. I know that this doesn’t cover everything and each company may have opportunities for more custom automations. But I’d love to know from experiences/projects on what can you realistically do? ( PS - I am NOT looking to buy another tool/vendor)

My issues are:
1. The automation should really be useful. If I spend a week building it and need 2-3 hrs a month for maintenance just so that it can provide what a simple screenshot covers, it probably doesn’t make sense.

1. Generally companies already have tools for cloud monitoring, EDR, etc. If a tool already flags an over privileged pod, or a misconfigured S3 bucket; it doesn’t make sense to set monitoring for that again?

2. I have been following the GRC engineering hype and I do believe that there is potential and I just don’t know enough. But there are some things which seem inefficient, not worth it, home project like, or sometimes just over engineered.

I’d love to exchange ideas on what someone actually implements through an organization and if they’ve truly found it to be worth it!

what do you enjoy? how'd you end up here?

our financial auditor wants a service organization report (ISAE 3402/SOC 1) on a purely internal, self-developed system with no user entities — is that even the right standard?

When we scope a smart contract audit, the boundary usually lands around the code the client controls. That sounds unremarkable until you look at what these systems delegate. A contract that checks permissions through an external registry, resolves its own logic through a beacon, and deploys proxies from templates approved elsewhere is calling out to three things the client may not own and we may not be engaged to review. We can see all of it, because the calls sit in the code in front of us. Reviewing it is a different engagement with a different budget.

We delivered four separate audits for one system, and all four came back with zero critical and zero high findings. That result is real. The contracts were well written and the project team fixed what our auditors raised. Every one of the four reports also named, in its Potential Risks section, two components that no audit had reviewed: the authorization layer that decides whether a caller may write to state, and the upgrade authority that decides which implementation each proxy runs.

A severity summary counts findings inside a boundary. It carries nothing about what sat outside that boundary, and it cannot, because nobody looked there. Those four zeros describe four passes over the same contracts, and a fifth audit of the same scope would produce a fifth.

We helped draw that boundary and were paid for the work inside it. I would make most of the same calls again, because the authorization layer belonged to another team and refusing to review anything until everything is in scope produces no review at all. What I notice is where the two facts end up in the document. The count goes into a table at the front, and the dependency goes into prose near the back, which is roughly where readers stop treating it as part of the finding.

What we see from the delivery side is which part of the report gets quoted back to us, and it is almost always the table. The scope section is the part that says what the table is a statement about, and it is the part that stays in the PDF. So the sign-off that the audit coverage was adequate for the filing usually happens on the count, by someone who has not looked at the boundary the count was taken inside.

Who signed off that your audit scope was sufficient, and were they reading the table or the boundary?

In a meeting last week security asked how we would find apps people built on ai app builders, and leaderships answer was we already have discovery tooling, use that. They mean ServiceNow Discovery, Device42 and a Faddom pilot that has been running for two years, and all three genuinely cover our laptops, servers and network gear.

But none of them can see a web app someone built on an AI builder with a database attached, no corporate infra at all. It's not on our network, not on our devices, not in any domain we control. Our entire discovery stack is very good at inventorying things that exist in our world, and completely blind to things that dont.

So the honest question: what are people actually using to find this stuff. If the answer is nothing, we find out when something breaks, tell me that too, at least then I'll stop asking vendors.

If you're doing third-party risk assessment on SaaS platforms, what levels of assurance do each of these certs actually provide?

I know there's more context than just the cert itself. For example, SOC 2 Type II has TSCs that can be scoped to the customer's needs (e.g. high availability requirements). Beyond that, you need to look at things like scope, exceptions, auditor's opinion, and the SoA. The report needs to be read and understood around the context of your organisation.

A few specific questions:

• Should SOC 2 Type II be the gold standard if you're procuring SaaS and want to reduce cyber risk?
• Does ISO 27001 hold up well for assessing SaaS vendors, or a lot less so?
• Should Cyber Essentials Plus alone raise red flags for an org handling large amounts of sensitive data, and only be accepted for low inherent risk vendors/

Handed the ask everyone's getting, write us an AI policy. I've shipped enough policies to know one written in a vacuum becomes a pdf people click past on day one.

Before I write a word I want the picture. Which teams use what, what data goes where, what's sanctioned and what's a manager expensing a subscription on a personal card. My gut says usage is wider and more sensible than leadership fears, and a policy that pretends otherwise shoves it underground.

Trouble is I don't have that picture, just anecdotes and two properly scary stories. Leaders who've done this, how did you get a read on usage before writing the rules, not after.

So I'm studying for the ISO/IEC 27001 Lead Auditor certification and need some clarification on how to understand the questions. My training material sometimes uses strict textual reading, but other times uses interpreted practice framing.

I'd like to how you'd have answered the questions below. Please also correct me if my understanding of all this is wrong.

Example 1: Answer is Interpreted

Question: What should the Statement of Applicability contain?

Options:"necessary controls determined through risk treatment (per Clause 6.1.3(c))" and "all Annex A controls with applicability decisions."

My thought: Clause 6.1.3(d) requires the SoA to contain necessary controls, justification for inclusion, implementation status, and justification for excluding any Annex A controls. Strict text reading of the Clause means not all controls are a hard requirement, only those deemed necessary by the organization.

Answer: All Annex A controls with applicability decisions. I think it is interpreted to fit actual practice, or it doesn’t follow strict textual reading.

Example 2: Answer is Strictly Textual

Question: True or false: "ISO requires the change management procedure to be documented."

My thought: Annex A 8.32 requires change management procedures to exist. Clause 8.1 requires documented information "to the extent necessary." I thought an organization should document change management procedures at least for audit traceability and consistency, thus "necessary" and True.

Answer: False. I think the reasoning is that no clause explicitly requires the change management procedure to be documented, just that procedures exist.

I understand ISO is deliberately vague, but for exam purpose, I find it confusing. How to distinguish these? Is the exam like this too?

I'm reading through ISC2's official CGRC textbook and hit a section that raised an eyebrow:

Setting aside what an exam wants us to memorize, treat them as identical in the real world feels completely off.

In my mind, using personal analogies highlights why they aren't the same:

• Appetite (Desire & Capacity): Like food—what you want to eat, your craving, and how hungry you are at a given moment. In business, this feels like an organization’s active drive for growth and what kind of risk they are hungry to take on.
• Tolerance (Limits & Pain): Like pain tolerance—a very specific, baseline threshold for how much discomfort or stress an individual (or org) can physically endure before something breaks. In business, this feels like the operational guardrail or budget limit—the point past which a risk is simply unmanageable.

To me, appetite is about drive and desire, while tolerance is about surviving the pain when things go wrong.

1. How do you define and separate these two terms in your day-to-day operations?
2. When communicating with executive leadership, do you find pushing this distinction actually helps, or do executives just treat them as buzzword synonyms anyway?

Peace.

Any practical tips as I join an audit team? I am representing my company for a surveillance audit and I want to navigate the audit professionally 🙌

So we had our first AI compliance audit last quarter. We walked in feeling prepared. We heard red teaming reports from launch, policy documentation, a risk register, and everything a typical team will have.

The auditor didn't ask about any of it. They asked three questions instead.

1. Show me evidence that you retested after each model update. We had pushed 4 model updates since our last assessment but we had no retesting between them.
2. How do you distinguish between a test that passed because the model was safe and a test that passed because the test itself became stale? I had never thought about that distinction and none in our team had thought of it.
3. If a regulator asked you to prove your AI was safe yesterday, not at launch six months ago, what would you show them? We had a point-in-time report from January but nothing to prove current safety posture. 

We could not answer any of it.

The auditor wasn't trying to cut us out. They are just asking the questions that matter now. I'm sharing them here because most AI compliance programs are built around launch milestones but not continuous evidence. If you can't answer these three, you are not ready for your audit either.

Hi everyone, in the context of NIS2 compliance we have to either show an ISO 27001 certificate (with some additional requirements) or satisfy a national battery of controls. Either way we will be audited and I would like to draw from your experience on real examples of evidences that an external auditor asked you to provide during an audit, so that we can better prepare on the nature and granularity of what is generally asked.
Can any of you who already passed an external audit give me some relevant examples of what they were really asked to provide ?

For a non technical person.. what are things to know about the limitations of it so that way I dont wrongly rate the vendor for something malattributed.

Also once u have a finding how to then flag it

In Ireland to be more precise, what would you say?

What type of GRC workbook have you created to track compliance related activities across your organization? Anyone willing to share a shell of it? We plan to use an automated GRC tool in the future but for now it’s in excel.

What have you found that has worked well as far as ensuring user access reviews are done and tracked and documented appropriately? As a GRC person you should be driving the key folks to perform quarterly or whatever the cadence is. How do you setup a reminder for yourself to check?

We're struggling with the grey areas between minimal risk, specific transparency risk, and high risk applications (Annex III). For instance, an internal HR tool that screens resumes for initial filtering. is that strictly high-risk under employment criteria, or can it be mitigated into transparency-only if humans make the final call? How are your risk committees documenting these borderline classification decisions?

Can someone point me in good free sources or advice of what is needed in an incident management policy?

Every scoping guide for segregation of duties starts in roughly the same place. Identity provider, cloud IAM, source control and CI, anything that moves money. That list is correct for most companies and it has a hole for anyone holding customer assets in smart contracts, because contracts carry their own privileged roles, and those roles get granted by a deployment script rather than by an access request.

A recent audit report I was reading covered a protocol split into three subsystem manager contracts, one for the vault, one for the AMM, one for the order book. All three had been granted the same manager role on the shared state contract, and the privileged functions never checked which manager was calling. The vault manager could write liquidity position state, the order book manager could modify deposit state, and so on across the set. Nothing in the live call graph exercised those paths, so nothing was broken on the day of review. A compromise or a botched upgrade in any one of the three would have inherited authority over the other two. The severity rating is the part worth sitting with. Impact came out at 4 out of 5 and likelihood at 2 out of 5, which puts the finding in the Low bucket, since in code-security terms it needs something else to go wrong first. Read as a control rather than as a bug it looks different, because one credential spans three functions that the architecture deliberately separated, and that is close to the textbook definition the SoD control exists to catch. A code audit prices the likelihood of exploitation, while the control prices the concentration of authority, which is why a Low in the report can still be the finding your assessor cares about most.

An assessor tracing ISO 27001 A.5.3 or the SOC 2 logical access criteria asks for a role matrix, an access review, and change records showing distinct people at each step. On-chain grants show up in none of those, because granting a role in a contract is a line in a deploy script that went through code review instead of an access request that went through approval. The check itself is cheap: list every address holding a privileged role in your deployed contracts, then see whether any of them appear anywhere in your SoD documentation. Your evidence can be complete and accurate for everything in scope while missing the layer that actually holds customer funds, because the scope boundary was drawn around systems people log into. If your contracts have privileged roles, is that surface inside your ISMS scope or outside it?

I saw this posted in my LinkedIn feed - just wondered if anyone here has tried applying it (or home rolled equivalent) yet?

https://csrc.nist.gov/pubs/sp/1353/ipd

In particular, they've used the COSTAR prompt model - which seems really well suited for compliance type work.

I'd be interested if anyone has tried applying that prompt model to other use cases - or has tried other prompt models

If so, message me. I've got a small consulting project for you.