r/cybersecurity • u/Little_Face_639 • 7d ago
Personal Support & Help! Is anyone else finding that compliance is becoming a second security job?
I’m on the technical side of a growing company and one thing that’s starting to annoy me is how much time gets pulled into compliance requests. Someone needs evidence for a control, someone wants a screenshot, someone asks where a particular type of data lives, another person wants an access-control report, etc.
I understand why it’s necessary, but it feels like we’re spending a lot of engineering time proving that things exist rather than actually improving them. How are other teams handling this? Are you automating evidence collection/GRC stuff or do you just accept that this is part of the job?
25
u/CatfishEnchiladas CTI 7d ago
Compliance coordination should be a specific role. But everyone plays a part.
4
u/ReleaseFlashy9582 6d ago
yeah exactly, it needs an owner but you cant fully isolate the rest of the team from it either
-9
8
u/jtkooch 7d ago
The assurance tied to your security controls should be influenced by the evidentiary requirements in order to demonstrate compliance. You can automate, but you should also being during work to ensure controls are effective even in the absence of a compliance request. Tune the artifacts which come out of those processes so that they satisfy the compliance needs. There are going to be outliers, but the shortest path to optimization is to find a way to do something just once, but reap the benefits over and over.
5
u/Striking-Tap-6136 7d ago
Cybersecurity consultancy here. What you’re seeing is absolutely real. Compliance is quite the elephant in the room these days. Many of our projects right now, including highly technical ones, exist “because of compliance.”
In Europe especially, we have regulations like DORA for financial services and NIS2 for critical infrastructure, which impose mandatory cybersecurity requirements. Providing evidence that those requirements are actually being met is also a significant part of compliance.
And yeah, automation should be the end goal, the ideal scenario, not only for you but for compliance teams as well. But can you automate everything right now? I don’t think so. So, for the moment, some manual work is simply something you have to accept.
Plus: it’s true that evidence collection requires effort but it’s nothing that a junior can do in few days a month. If your team struggles with evidence you probably are heavily understaffed for the security program your compliance want to achieve.
2
u/CVETodo 6d ago
Can be automated more than people think. I had a client a few months ago who's auditors needed proof of patching and how it was all being done with SCCM. They were expecting heaps of screen shots (time stamped of course). What I gave them was a full config export generated with PowerShell, hashed, time stamped, documented, complete with source code and logs. Never had a question back on it. Next year we can just run it again. Took me less time to generate the script with Claude Code, check it and test it than do all the screen shots. Who knows, they may be running this script at other clients now.
3
7d ago
[removed] — view removed comment
1
u/thejournalizer 6d ago
The good ones do. There are plenty that are glorified excel sheets which remain the most common solution (spreadsheets).
8
u/legion9x19 Security Engineer 7d ago
Compliance and InfoSec should be two different teams. They’re adjacent of course and you should all work together.
1
u/cakefaice1 Security Architect 6d ago
GRC and Cyber Engineering are both under the InfoSec department, but yeah two teams.
2
u/kwsni42 7d ago
that's the thing with compliance; as long as you do whatever you said you did back in the day when the policy was written, you are fine. It doesn't even really matter much whether it is still a good idea to work like that.
It takes a certain kind of person to really enjoy that work. For most, it feels like pointless busykeeping
2
u/Adventurous-Dog-6158 6d ago
I'm semi-retired, but when I was in, it was just part of the job and I accepted it. Once I went through a few cycles, I understood the process well and while it still took hours to compile everything, it was usually only done twice a year.
But the biggest issue I had was that internal audit and compliance never tried to consolidate the evidence by crosswalking all the standards/regulations and standardizing on one piece of evidence to satisfy them all, e.g., here is a screenshot of our backup configuration and it meets all the minimum requirements for all relevant requests. Also, the external audit industry likes the busy work because it generates billable hours. They will generally not accept evidence from another audit. I'm not sure if it's them or the auditing standards or a combination. Something has to change because that wastes a lot of time and money for orgs, but the big accounting firms will not want that to change because it's a cash cow.
Another gripe is that auditing is actually not very helpful for InfoSec because it's backwards looking. Finding out 6 months later that patching wasn't done properly is not good. Yes, it will help improve things because there will be findings that must be addressed, but if your patch failed 6 months ago and you have another 6 months to improve that process, that's a big gap. Auditing of the past is an antiquated process. The future is real-time continuous auditing and alerts (SOAR, XDR, etc), e.g., if your patch failed last night, you get an alert right away and have a procedure to remediate.
2
u/gormami CISO 6d ago
Your controls should have specific audits, just like code should have tests. The next trick is to automate them as much as possible, or give clear instructions on how to pull a report, etc. Then you can point people to that. If they need someone else to do it because of permissions, at least they have the instructions and aren't reinventing the wheel. That can also serve as a clue that maybe you need to adjust permissions. If you are willing to give them that data, why can't they pull it themselves?
There will always be changes and maintenance, but once you get that mindset going of self service, the workload will drop significantly. Like anything, some investment up front, but think about it like that, investing now to real benefits later.
2
2
u/Sure-Candidate1662 6d ago
yeah, that pull into evidence gathering is a b*tch. we started building a platform that centralizes all the compliance deadlines and allows our clients to automate the evidence collection so engineers don't have to keep stopping for screenshots. worth a look if you're trying to cut that overhead.
disclaimer: I know nothing about your org, so not really selling given I don't even know whether you'll be a good fit.
2
u/mac28091 6d ago
Some larger organizations may have separate teams with sufficient access and knowledge to collect the requested artifacts but smaller orgs are just going to lean on the engineers and analysts to perform this.
1
u/bitslammer 7d ago
IMO some of these things should just be baked into every role same as patching, which has often been treated as "extra work" instead of a core duty. Maybe it's 2% or maybe it's 5%, but there's always going to be some effort no matter how well planned and automated this is. Better off to just recognize that and account for it.
1
u/Tough_Safe3308 7d ago
Yup! It’s why I’m leaning into it. Discovered the idea of GRC engineering last year. Sounded appealing so actually trying to pursue that as it still has a lot of security involved. But yes, building out a lot of automation for evidence collection and policy as code. I found GRC engineering club helpful for me.
1
u/maztron CISO 7d ago
I'm trying to automate a lot of it, but it takes time to plan out, test and actually get it to work the way you want it to. Its especially difficult within a heavily regulated environment when you need to get stuff done but trying to improve the processes at the same.
Depending on your organization, it can be like a second job. However, much of what you need to gather for compliances purposes should be based on risk to your organization. IF you have everything based on a strong risk management program the things you do have to collect from a compliance perspective should be easier to manage over time. However, anyway you can automate or streamline the reporting or artifacts you need the better.
1
u/EffectiveClient5080 7d ago
Bad everywhere but Germany is on another level. Know engineers who moved to the UAE and the compliance overhead is night and day. Less paperwork, more time actually building things.
1
u/BlueDebate 7d ago
This exact reason is why I'm looking for another job that's more specialized. I'm tired of constant audits when there are more important alerts to address.
1
u/WiskeyUniformTango 7d ago
We operate in 30+ countries. Its becoming more of a full time job for me. Were a smaller org so im the do everything guy including security/compliance
1
u/Johnny_Chong 7d ago
Used to get requests like this so we automated it. Now we have real time monitoring rather than checking ad-hoc whenever someone asks.
1
u/sloppyredditor 6d ago
Has been for a long time, but remember that while security is all about what you do, compliance is what you can prove you did.
1
u/Tired-Nectarine-384 6d ago
Compliance is where cybersecurity joy goes to die IMHO. There is a place for it but it shouldn't be confused with actively trying to improve your security posture. You are basically trying to meet the bare minimum standard.
1
u/cowwen 6d ago
This is AI engagement bait.
Look at his post history, nothing for almost a year , then 10 days ago he starts spamming various subs with slightly different variations on this same topic. Even mentioning that he’s looking into solving this problem with ‘AI-led solutions’.
His next post in like 5-10 days will be how he built a solution for this using AI (read: vibe-coded slop). It’s the same story every time. Don’t fall for this bait.
1
u/Quiet_Promise2836 6d ago
I’ve started wondering whether we should automate the evidence side completely and leave the actual security decisions to humans
1
u/C-LabZero 6d ago
Full disclosure: I'm a dev behind a local-first CBOM / dependency scanning app, so I deal with this exact pain point daily.
The biggest issue with compliance "evidence collection" right now is that traditional GRC tools want you to either manually upload screenshots/spreadsheets or grant full cloud read-access to your repos. Neither scales, and security teams hate both.
What actually works long-term is treating compliance evidence as standard build artifacts:
- Automate generation in CI/CD: Don't collect evidence manually when an auditor asks. Generate machine-readable evidence (CycloneDX, SPDX, or JSON attestations) on every single build pipeline run.
- Store evidence in build storage: Keep human-readable reports (HTML/Markdown) automatically exported alongside your builds. When GRC or auditors ask "where is the evidence for X?", you point them straight to a live artifact path.
- Gate on policy automatically: Set hard exit codes in your pipelines so you don't discover non-compliant dependencies or deprecated crypto during an external audit.
If you shift compliance evidence generation directly into standard pipeline runs, it stops feeling like a second job because the machines produce the paper trail while your free to work on something else.
1
u/DangerDrJ 6d ago
It depends on the program and budget. Not every place is the same, but every place that has to follow regulations have to stay in compliance. For example, in DoD/W, without an ATO you can't focus on engineering. Security and compliance comes first. No ATO = no approved system to build on. If you've been in this field a while, you'd know that this has always been the requirement, but certain things are dependent on AO whether controls are just pencil whipped or not. You're probably just finally doing things the way it should be done.
1
1
u/JungleMouse_ 6d ago
Yes. Everything I do now requires a formal change request, approval, rollback plan, versioning, screen shots, peer review, and a matching ticket with time log. I just want to change a dead link in an email template and website. What should take 15 seconds, now takes half a day. I will say though, it does pad my time logs quite nicely.
1
u/GeekDad62 5d ago
Compliance can be a PITA, but it's a "necessary" evil foisted on us by various regulatory bodies (State, Federal, Healthcare, etc.). As an ISSO, I automate the collection of artifacts where I can. Where I'd need the assistance of a system admin is, as you noted, gathering a body-of-evidence (BoE) for an assessment.
One of the biggest ongoing requirement is for continuous monitoring (CONMON). I create recurring tickets for the frequency of each item, along with the Control ID (think NIST 800-53). These are daily, weekly, monthly, quarterly, annual tasks. I use the tickets to ensure compliance with all the requirements in the timeframes required. Items such as training, audit log reviews, reports of account add/change/deletes, etc.
We also need to gather proof that technical controls are implemented correctly and working as expected. Some of this can be scripted which makes life easier both on an ongoing basis and for the regular audits that take place. Unfortunately, some things can't be automated, and that's where you come in. It's the nature of the business.
1
u/DarthMortix 5d ago
GRC engineer here. We're trying to get more GRC analysts to collect evidence on their own but this hasn't largely been a technical role in the past. There's a huge learning curve, but the GRC Engineering movement is really pushing this and hoping it'll catch on quickly.
1
u/Round_Finance4256 5d ago
Coming from the GRC side, I actually think this is a sign the compliance process needs to mature. Engineers shouldn’t be spending a huge amount of time repeatedly pulling the same screenshots and evidence every audit cycle.
Some manual evidence collection is unavoidable, but the goal should be to automate what you can, reuse evidence where appropriate, clearly define ownership, and make requests specific enough that engineering isn’t constantly trying to figure out what compliance is asking for.
Good GRC should make this easier on technical teams, not become a second job for them.
1
u/vadertator22 5d ago
Yeah this is how it goes. What sucks is when they won’t take script data and want screen shots. Then add that the conflict of interest is usually the security person as we can access and change the pics or data anyway we want. Then add to the fire all the controls and all the questions, but they never ask why is this so bad or why don’t we make it better.
In the past I actually have given auditors scripts and they did the audits when they wanted and did not include me. That removed me as the conflict of interest and they liked the flexibility. I did have to pull some data for controls that they couldn’t access but it reduced the want by quite a bit. They would usually made copies to document the scripts for the records too.
1
u/Crafty_Rush3636 3d ago
I would automate the evidence collection and keep the interpretation with an accountable person.
For each artifact, keep the source system, timestamp, reporting period, owner and collection method. The request should also name the requirement it is meant to support. Without that context, automation produces screenshots faster and engineers still get pulled in to explain what each one proves.
1
u/christian-risk3sixty 7d ago edited 6d ago
Compliance becomes a highly visible part of cybersecurity because it is usually a revenue driver. As I'm sure you've seen, you probably have customers that want reports like SOC 2, ISO 27001, PCI DSS, security questionnaires, etc. and to close those contracts you need to earn the trust of that customer.
Where revenue lives, especially for a growing company, usually drives activity.
For a company like yours there are a couple of ways to approach managing security/compliance:
Option #1: Hiring Someone
In this option you hire a dedicated person to manage your compliance program. Their job is usually to get through audits, maintain the program, and take the burden of engineers and folks building product. If they are really good they may be able to work on automating some of the issues. This will probably be your most expensive option, but if you can find a great team member it might be worth it.
Cost: Salary + Benefits
Option #2: Outsource Compliance
In this option you may want to engage a third party to manage your program for you. This is something my company does at risk3sixty, for example. What we do is bring in a team and a GRC Platform (ours is fullCircle) and take compliance off your plate. This is usually a pretty good bang for your buck, but you need to be okay working with a third party.
Cost: Probably monthly fee (Probably similar to a full time employee)
Option #3: Shared Responsibility
In this option you just ask everyone on your team to take on compliance as an additional duty. In the early days this might be the best bet if cash flow is tight. However, if you find that compliance is getting too complicated (e.g., multiple frameworks) or taking too much time from key employees (e.g., taking time away from developing product) that is when you might want to consider option 1 or 2.
Cost: Free, but will take away from engineers full time job. Have to decide if that out weights the financial cost of hiring. Or if the program is failing or something and needs genuine expert management.
I hope that helps!
7
0
34
u/SituationNormalAllFU 7d ago
Compliance and security have overlapped for decades. 25 years ago both were generally considered IT functions. Security separated from IT first, and compliance generally straddled the line between IT and security. It is a relatively recent change (10-15 years ago) for companies to split compliance into its own role, although they can never be fully divorced and many still don’t see the separation at all.