How do you know which controls are high risk before the auditor tells you?
Posted by Accurate-Yam5366@reddit | sysadmin | View on Reddit | 18 comments
CS here building a tool around audit prep. Trying to understand if this is a real problem before I invest more time in it.
From what I've read, most companies don't know which controls are high risk until the auditor tells them. Is that actually true or do compliance teams already have a way to prioritize before the audit starts?
AndyceeIT@reddit
Sorry what does "CS" stand for? Computer Scientist? Cyber Security assessor? Customer Success operator?
Accurate-Yam5366@reddit (OP)
Computer Science
AndyceeIT@reddit
Ok so you're a student?
I ask because the question is a bit weird to me, or I've misunderstood.
When you build or maintain a system, environment, network etc you consider cost, functionality, security etc.
It's obvious that - for example - enabling an insecure remote access protocol directly from the internet is a very high risk. Failing to apply a low urgency security patch for a month is a much lower risk.
There are lots of "in-between" risks, but if the auditor is just referring to a spreadsheet then it's not very complex
I presume the audits you describe
AtarukA@reddit
Pet peeve here, I'm unsure whether this is a US thing with acronyms, or if it's just an IT thing since I am biaised with mostly speaking English for IT.
jaivibi@reddit
We didn't know our overexposed file shares were a problem until an auditor flagged nested AD group access mid-engagement, after that we started, using Netwrix Data Access Governance to correlate data classification with actual access paths so we had a risk-ranked view before anyone came knocking. Not a silver bullet for every control domain, but for data access risk it gave us something concrete to prioritize against instead of just a flat permissions dump.
bitslammer@reddit
What do you mean by tools being "high risk?"
Hotshot55@reddit
OP doesn't know.
Accurate-Yam5366@reddit (OP)
Fair point.I used the term loosely. What I meant was controls most likely to have deficiencies based on evidence difficulty and audit frequency. Still learning the precise language. Thanks for the correction though!
Curious201@reddit
the first thing i would do is build a tiny risk register instead of trying to guess from memory. list each control, what can go wrong if it fails, what system or process it touches, who owns it, and whether there is already evidence that it is weak. anything tied to money movement, privileged access, customer data, backups, legal/compliance, or single points of failure should rise to the top pretty quickly. for each one, ask two boring questions: how bad is the impact if this fails, and how likely is it based on what we have actually seen. you do not need a perfect framework on day one. you need a defensible way to show why you looked at payment approvals, admin accounts, access reviews, backups, change management, and vendor access before low-impact checklist items.
Accurate-Yam5366@reddit (OP)
This is essentially the spec.Risk register per control, impact times likelihood scoring, evidence flagged, owners assigned, defensible output.That is what I am building.Thank you for making it this clear!
itishowitisanditbad@reddit
..they do appropriate research to know.
Thanks for being yet another CS making yet another audit prep tool with absolutely zero background or knowledge in the subject.
Super helpful.
Accurate-Yam5366@reddit (OP)
Noted. For context I have observed internal audits firsthand and spent time across QA, security analysis, and compliance support. Aware that another checklist tool is not what anyone needs, trying to figure out what an actual system looks like. What would you build instead?
itishowitisanditbad@reddit
I would wait for a problem to be solved before just building a tool arbitrarily in a space i'm not familiar with.
Why is the only option, to build?
This is what happens when you go to solve... nothing specific.
Accurate-Yam5366@reddit (OP)
Fair point on not building blindly,that’s exactly why I’m asking. Before an external audit, how do you currently identify or rank high-risk controls?Is it based on prior audit findings, control failure rates, inherent risk scoring, or something else?
thortgot@reddit
Inherent risks are objective. You can evaluate multiple security frameworks across the same entity and get different results for the same risk. Why?
Because they are different interpretations, focuses and understanding of risk. They have different thresholds and other measurements.
I don't see how you build anything that extrapolates all of that.
itishowitisanditbad@reddit
Read them.
Understand the implication of them.
Consider the risk mentally.
Because foundational experience exists to understand the risk of things.
Its based on reading the control and understanding what it is and what it means.
Lets go over your options you provided.
1) prior audit findings - i.e "being told its high risk by someone else" ?
2) control failure rates - How would this possibly impact the risk behind it?
3) inherent risk scoring - What does this MEAN other than what I already said? i.e do appropriate research to know? Foundational knowledge?
Accurate-Yam5366@reddit (OP)
Thanks, that makes sense. I’m trying to learn more about how this works in practice across teams. So far I’ve mostly seen challenges around organizing evidence and tracking everything pre-audit. Is that your experience as well?
alpha417@reddit
This reads as "i want to make money off a thing? What thing should i make?"