How to Pivot Into Compliance (With or Without a Security Background)
Compliance is having a moment, and it’s not by accident.
Between the rapid adoption of cloud computing, the mind-boggling explosion of AI-driven products, and increased regulatory scrutiny (oh hey, EU), organizations have fire under their behinds to prove trust, not just claim to be trustworthy anymore. That pressure has turned GRC teams into strategic business functions rather than checkbox exercises.
And recently, I’ve more than a few folks come to me wondering how they can get into compliance, and if their security background, or lack thereof, will help or hinder them.
And so, if you are someone who’s been asking:
How do I get into compliance?
Is GRC just paperwork exercise?
Will I be too technical?
Do I need a security background to succeed?
Voilaaaa! This guide is for you :)
Below is how I would approach pivoting into compliance today, with the knowledge I’ve gained after years of working in GRC and Security across fast-growing, technical organizations. Now listen, I like to be thorough so it might be a little long. But I promise I got you so you are not confused anymore.
Step 1: Understand the Domains Within Compliance (GRC Is Not One Job)
Most companies group Governance, Risk, and Compliance (GRC) into a single team. The reality of this is that GRC is three distinct disciplines with different responsibilities, tools, stakeholders, and mindsets. Let’s break them down:
Governance: Setting Direction and Guardrails
What is it? Governance is about how decisions are made, documented, and enforced across the organization.
What this looks like in practice:
Being responsible for defining, enforcing (!), maintaining, and defending (!) your org’s security and privacy policies both internally and externally. I have had experience with orgs who’s policy says something but enforcement isn’t there for employees to follow. It puts you in a very difficult and hard situation. Get a handle on this asap.
Establishing ownership and accountability across the scope of your environment: meaning you should be familiar and have scoping documents, the current tech stack, all-of-it.
Deep diving into your org’s business goals and figuring out how to align your security initiatives and priorities with them (get comfy with your internal wiki)
Creating repeatable processes, not a pile of one-off fixes. Because 6 month’s from now when you have shifted projects, priorities, or personnel it will be VERY difficult, annoying, and sometimes impossible to backtrack and create sustainability. You will just be creating bandaids. It’s helpful to figure out a way to be flexible with long and short term thinking when you come up with solutions.
Mindset you should adopt/develop: Strategic, systems-oriented, long-term thinking
Good fit it you enjoy: Structure, writing, clarity, influence, leadership alignment
Risk Management: Understanding What Matters Most
What is it? Risk management is about identifying, assessing, prioritizing, and treating risk so the business can make informed decisions.
What this looks like in practice:
Running enterprise risk assessments: meaning you are the one developing the question sets, identifying the audience, conducting interviews, synthesizing information, and presenting it in a way to inform the business of what it should be prioritizing next.
Translating technical risk into business impact: I’m not talking: “I worked on vulnerability management and incidents” to your manager. You need to be saying: “I assessed security vulnerabilities and incidents through a risk-based lens, evaluated the likelihood and business impact, and worked with control owners to prioritize remediation efforts. Here’s the criteria I used for prioritization and here’s the documentation for residual risk and risk acceptance decisions for leadership” It’s a lot I know. But it’s the language the business, and not security audiences, will understand.
Helping leaders decide what to fix now vs later: kind of following the thought process of my last bullet, when you are presenting solutions you should be doing it in a way that gives leadership a way to figure out what to prioritize and why.
Tracking residual risk and risk acceptance: this is especially true if you have a small team and no formal risk management team (or a component one). It’s the R in GRC. You will have responsibility to follow up on residual risk, re-evaluate risk acceptances, and continuously monitor risks to ensure they remain at or below your org’s acceptable risk tolerance (and if you don’t know this, you should get that conversation started asap).
Mindset: Analytical, curious, comfortable with uncertainty
Good fit if you enjoy: Analysis, trade-offs, decision support, business context
Compliance: Proving What You Do (and Doing What You Say)
What is it? Compliance ensures the organization can meet its external and internal requirements and can prove this to auditors, customers, and regulators.
What this looks like in practice:
Managing audits and assessments: This is all about executing on your yearly audits (think ISO 27001, PCI-DSS, TISAX, Internal Annual Risk Assessment)
Mapping controls to frameworks: You ever look at how many tools you have and ask yourself “wait what is this tool being used for?” and someone nukes it but turns out it was fulfilling your third party risk management program for requesting information? Very specific but let’s hope you are not in that situation. It’s important to have a map of what tools, people, or processes are fulfilling the scope of your control environment.
Collecting and validating evidence: When you are executing on an audit, say PCI-DSS for example, they might ask something like: how are you ensuring vulnerabilities in your tech stack are being identified, monitored, treated or remediated? If you have a standalone team, with a repeatable process, and can go ask your control owner for this, that is great. Unfortunately, more often than not this will fall under the GRC team, meaning you will have to log into Tenable (its a tool), run a scan, validate the report, register any risks, run through the treatment process, re-run the scan, and then submit for PCI approval from Tenable. No exaggeration.
Monitoring control effectiveness over time: Aka continuous monitoring. Aka how are you ensuring that the control you put in place to make sure everyone is taking their security awareness training is actually happening. And if its not, what are you going to do about it? Same thing goes for that control to ensure firewall effectiveness.
Mindset: Detail-oriented, process-driven, collaborative
Good fit if you enjoy: Execution, coordination, documentation, continuous improvement
Domo Note: It’s important for me to say here that you don’t need to love all three to work in GRC. Or even know all three. Many people specialize as teams mature. But you need to understand a team’s maturity and that can be difficult to assess during an interview. So better for you to know now than after accepting a job offer that is completely different from the one you were hired for.
Step 2: Know the Frameworks (You Don’t Need to Master Them All)
I’ve seen quite a lot of discourse on whether or not frameworks are helpful and if you should learn them. Let me just say this: Frameworks are the shared language of compliance. And you aren’t speaking the same language of others in your field, how can you expect to be effective?
You don’t need to memorize every control. You need to understand why frameworks exist and what problems they solve.
Compliance & Regulatory Frameworks to Be Aware Of:
Depending on the industry and geography, you may encounter:
ISO/IEC 27001 (Information Security Management)
SOC 2
PCI DSS
FedRAMP
GDPR and CCPA
ISO/IEC 42001 (AI Management Systems)
Emerging EU regulations around cybersecurity, privacy, and AI
What matters more than the above list:
Understanding that frameworks are risk based, require evidence of design and effectiveness (how did you put this process together and how did you test that it works all the time?), and evolving overtime as technology threats change (ex: AI).
Risk Management Frameworks:
Commonly used frameworks include:
ISO 31000
FAIR
COSO ERM
NIST Risk Management Framework
NIST AI Risk resources
ISO/IEC 42001 risk concepts
Do not expect to be an expert in all of these. Instead, focus on how risk identified, assessed, treated, and communicated. That process is the gist of many of these frameworks, give or take an extra step or calling a step a different name.
Security Governance & Maturity Models
While governance isn’t always tied to a single framework, you should understand:
Information security policies and standards
Access management programs
Secure development lifecycle practices
Step 3: Know Your Stakeholders (Compliance Is a People Job)
One of the biggest misconceptions I have experienced and witness from those diving into compliance: that the GRC team is left alone and works mainly alone.
GRC is a high-touch cross-functional team.
What does this mean exactly? Well I know most people know GRC teams work with external auditors but they also work with:
Internal Audit Teams, Risk Management Teams, Engineering and Infrastructure teams, Product and Design teams, Finance, HR, Legal, Procurement, and various levels of leadership
I am very grateful to have been in multiple positions that have forced me to wear many hats (typically because I’ve worked with small-businesses/startups). This experience had me having to get over titles and realize I need stuff done and people are people. Now, I don’t mean to just email the CEO because you need help with an audit report. I mean get comfortable with the fact that you will have to interact with many different types of people and teams to solve your challenges and it’s important that you:
Know what each group cares about
Know the language of each group
Know how to translate requirements into their language
Continuously build trust and reduce friction
It is an understatement to say that strong communication skills are core to the role.
Step 4: Identify the Skills You Already Have (You Likely Have More Than You Think)
GRC has become more technical as environments have grown more complex. And I know for a fact that many of you already have transferable skills, you just need to identify and translate them.
For example:
Project management → audit coordination, control tracking
Engineering or IT → understanding system architecture and controls
Incident response → risk assessment and control gaps
Vendor management → third-party risk management
Writing or documentation → policies, procedures, evidence narratives
Teaching or training → security awareness programs
You do not have to start from zero. You need to get familiar with your strengths and reframe your experience.
Step 5: Understand What Roles Actually Look Like
Before you get on Linkedin, or any other platform to apply for job, get clear on the role you want. This will require some reflection and time. Finding blocks of time might be hard for some, so start small: one hour goes a really long way.
Here are some reflection questions you can take a few minutes to answer today:
Do I want to focus more on strategy or execution?
Am I comfortable wearing multiple hats? What hats am I even interested in wearing?
What technical or leadership skills are already strong, and which ones do I need to improve on?
Some examples of roles you can commonly find that align in GRC are:
Risk Manager
Policy or Governance Manager
Controls or Compliance Manager
Third-Party Risk Analyst
Information Governance or Data Classification Lead
Security Awareness Program Manager
Domo’s Note: Please be aware, even if you aim for leadership positions that talk about focusing on strategy, 9/10 you will be required to be hands-on to some degree. So dispel from your mind the notion that you will have to choice: to be competent and successful in this field you should be both. At times you may be more strategic than hands-on or vice versa. You should get comfortable switching between both.
Step 6: Adopt the Right Mindset for Success in Compliance
In my experience leading compliance teams, we’ve thrived when:
The business mission and priorities were understood by compliance leadership
Compliance leadership is able to align compliance activities to that business mission and priorities
The team can balance accuracy, methodology, and thoroughness with the reality of the real world (that changes every day)
We got comfortable with ambiguity and iteration
When you’re on the GRC team, you are representing the organization to external and internal auditors and customers. That means you should know how controls are implemented, why they exist, and that its effectiveness is ongoing.
Step 7: Know the Tools (Concepts Matter More Than Brands)
In a GRC role, you will encounter a variety of tools you may or not be familiar with. If you see one you don’t know or haven’t worked with before, you should at least pick one to look up and try and find an online demo or product papers to learn about what it does or what it tries to solve. For example:
Audit and evidence collection tools
Cloud provider security services (AWS, GCP, Azure)
Vulnerability scanning tools (e.g., ASVs for PCI)
Modern GRC platforms that centralize compliance efforts
What you should care about most is the scope of your environment, where controls live in the tech stack, and how evidence is generated and validated.
If you made it this far, thank you! Let’s talk about taking your first steps to pivot into GRC
I want to break this down into two options: if you are brand new to the field or coming from a Security/IT background
If you are brand new: don’t try and do it all at once
Pick one framework (ex: ISO 27001) and get familiar with the domains of the frameworks (think: access control, continuous monitoring, vulnerability management). What is key here is not trying to memorize individuals controls (that will absolutely drive you down a rabbit hole). What is important is that you understand that ISO cares about access control and how you handle identity management. But so does PCI. Now you know one domain that can apply across many frameworks (let’s work smarter not harder).
Practice reading audit reports and control descriptions. If you already work at an org, you should absolutely be able to see this (get cozy with your internal GRC team. Great for learning and if there are future opportunities).
Get comfortable with risk and begin learning about risk management principles and concepts.
Volunteer to help with compliance adjacent work where you are (again, if you work at a company I found it has been much easier (and very welcomed) to get cozy and show genuine curiosity with a team I want to pivot to)
If you are looking to pivot from Security or IT: great, you have a foundation to build upon
Audit your current work. With the tasks you do everyday: does anything map to controls? Who could you ask?
Are you already cross-collaborating? If not, are there any opportunities where you could? There is always something to solve with someone. Go have more conversations and coffee/tea chats.
Strengthen you communication and documentation skills. How are you expressing yourself? Are you speaking the business of the language or your audience? Is it working?
Start to position yourself as someone who understands both the business and technology. Compliance supports the business. It’s time to put the business hat on.
Final Thoughts: Now is a great time to get into compliance and it can be a career of leverage
Compliance sits at the intersection of technology, business, risk, and trust.
It is a field that rewards people who can think in systems, communicate clearly, and align security with real-world business needs.
If you are looking to pivot into a role that is growing, evolving, and increasingly strategic, compliance is definitely worth a consideration.
If you are reading this and realizing you want accountability, feedback, or a more hands-on way to translate your experience into a compliance-focused role, I offer 1:1 coaching for professionals navigating this transition. Please visit my website, here, for more information.
