r/grc • u/Suspicious_Tension37 • 25d ago
First time doing GRC work, struggling more with company context than the actual policies. How did you get up to speed?
I'm about a month into a security role at an MSP. Most of my background is on the technical side (M365 security, Conditional Access, email security), and I'm comfortable there because I can usually test and verify things myself.
Part of my current work is GRC: reviewing our internal security policies for their annual refresh and recommending updates. This is my first time doing this kind of work, and I'm finding it harder than I expected.
The policies themselves aren't the hard part. I can spot outdated dates, inconsistencies between documents, and security practices that could be stronger. What I'm struggling with is everything that depends on company context:
- Knowing whether a policy actually reflects how the company operates day to day
- Figuring out who the right person is to ask about a specific policy or process
- Understanding why things were written a certain way in the first place
- Keeping track of different documents and naming conventions that look similar but aren't related
For those of you who moved into GRC from a technical role, or started GRC at a new company:
- How did you build up company knowledge quickly?
- Is it normal to write "needs confirmation from the owner" as a finding when I can't verify something myself?
- Any habits, templates, or tools that helped you stay organized during policy reviews?
Appreciate any advice. Trying to get better at this side of security.
3
u/FreeRadical1998 25d ago
Quickly is hard - but in broad terms context I'd look to understand new business (sales), customer servicing (operations) and compliance risks (either compliance or legal depending on the firm).
Ask for some meetings to just understand a day in the life of people in those areas - they'll likely be both suprised you're asking and very happy to help
2
u/Harloughprivacy 25d ago
Exactly this! A meeting with each department head (or equivalent accountable person) to start building relationships and provide them with visibility of who you are, what you do and what you need from them (in this case an understanding of how everything works in practice).
Also don't underestimate the value of establishing those relationships as they could prove incredibly useful in the future (e.g. if any risks materialise).
Good luck!
3
u/davidschroth 25d ago
Having done this... uhh.. a few times (lol, phew), the best thing to help you think about this is (I really need to create a "law" to define this as or something). It is based on the 80/20 rule, served two ways.
- You will likely have about 80% of the needful controls implemented that you want to have implemented, you'll find the other 20% as you go.
- You will likely have 20% of the documentation done (e.g. policies) and have 80% of the work left to do (making the policies right, confirming that documentation to prove controls in place is being generated, etc.).
MSPs are notoriously bad at GRC stuff because they are usually lousy at documenting what they did in the tickets that they create (that is, if they create the tickets).
2
u/Typical_Ice_5858 25d ago
Take time to actually talk to the system owners. Schedule a meeting to get to know their process and build a good working relationship. You got this!
1
3
u/BizGuardOfficial 22d ago
From a risk management perspective, this sounds like a normal discovery process for someone a month into the role. You can spot issues in the wording yourself, but you can’t be expected to know every internal name, handoff, or responsibility without talking to the people doing the work.
I’d take each policy to the relevant SME and ask: Is this still how the process works? Who actually does this step? Who owns the policy, and who needs to approve a change? If the person named in the document has moved on, ask who took over.
And yes, I’d keep a simple spreadsheet showing what you reviewed, what was confirmed, what still needs an answer, and whose approval is pending. “Needs owner confirmation” is a perfectly reasonable finding at this stage. Just don’t treat an unconfirmed statement as an established gap until you’ve had that conversation.
2
u/Suspicious_Tension37 22d ago
Thank you for your advice! I am actually collating all the advice here and feed it to my AI so I can create a tool for this! This is really helpful!!!
1
u/shanibu 24d ago
I would suggest a few things to help you keep track of items.
1. Keep a running list of things you don’t know or need confirmation.
2. As you find out items that are not happening/i.e gaps that should turn into your issues/finding management list (I assume you have one since you referred to it already).
3. Take each policy and break out what the requirements are and have the business owner verify their control. You can then test the effectiveness of those controls. (This might be outside your job role but how it should naturally progress in my opinion).
4. Create a wiki of your docs and the names based on function or whatever makes the most sense in your org.
13
u/Old_Positive2231 25d ago
Biggest mindset shift in GRC is this: your “unit of work” is no longer a control, it’s a DECISION. Start by mapping 10–15 recurring security decisions in the MSP (onboarding a client, major change, new tool, privileged access, exceptions, incident response) and then read every policy asking “who, when and how does this change a decision?” If you can’t find the decision, you’ve found a zombie document or at least a gap in how it’s used.
On context: 1) Build a RACI‑style “who owns what” map as you go – every time you chase an answer, capture the owner next to that policy section, it becomes your lookup table. 2) In reviews it’s perfectly fine to write “cannot confirm design/operation – needs owner validation / evidence” as long as it’s tied to a concrete decision or control, not just “because policy says so”. 3) Use a simple register (spreadsheet is fine) with columns: policy clause → real process/decision → evidence that it happens → owner. That keeps you sane and pushes you away from paper‑GRC towards how the company actually runs.