GRC Analyst Interview Questions

“I started in IT support, and the part I liked most was never the ticket itself, it was working out why the same problem kept coming back. When our company went for its first security certification, I volunteered to help collect evidence, and I realised I enjoyed that bridge between the technical team and the auditors. I understood enough of the systems to ask the right questions, and I could explain the answers in plain words. Since then I've done a course on risk management and helped run two internal audits. What keeps me here is that GRC touches every team. One week I'm reading a vendor's security report, the next I'm helping HR fix their leaver process. I want a role where I own that end to end.”

“I respect hands-on security a lot, and I've done some of it in labs. But I noticed my strength is different. I'm good at seeing the whole picture, asking which risks actually matter to the business, and writing things down so other people can act on them. Penetration testers find the holes, the operations team watches for attacks, and GRC decides which risks the company will fix, accept or transfer, and then shows auditors and customers that it's really happening. That joining-up work is what I enjoy. I still keep my technical side alive, because I can't test an access control or challenge a weak answer from an engineer if I don't understand how the system works. So I see it as a different lens on the same goal.”

“Inherent risk is the level of risk if you had no controls at all. Say we store customer records in a cloud database. With no access control or encryption, the chance and impact of a leak would be high. Residual risk is what's left once you count the controls that really exist and work, like single sign-on, encryption and quarterly access reviews. Maybe that brings it down to medium. Risk appetite is the level leadership has agreed the company can live with, usually written in a risk policy or statement. So the decision is a comparison. If residual risk sits within appetite, we monitor it. If it's above, we either add controls or a senior owner formally accepts it, with a reason and a review date. The key point is that residual risk should only count controls you know work, not ones that exist only on paper.”

“A good entry reads like a sentence, not a label. For the old server I'd write: because the billing application runs on an operating system that no longer gets security updates, a known weakness could be used to get into the server, which could expose customer billing data and stop invoicing. Then I'd note the existing controls, say it sits in its own network segment and only the app servers can reach it. I'd rate inherent risk high and residual maybe medium-high. The treatment would be to reduce it: move the app to a supported platform by a set date, and meanwhile tighten network rules and add extra monitoring. The owner is the head of the billing application, not the security team. I'd add a review date and link it to any exception we've granted for the patching standard.”

“A SOC 2 report is an attestation report, written by an independent CPA firm, about a service organization's controls. It's measured against the Trust Services Criteria. Security is always included, and the company can add availability, processing integrity, confidentiality and privacy depending on what its customers care about. A Type 1 report says the controls were suitably designed as of one date. It's a snapshot. A Type 2 report covers a period, often somewhere between three and twelve months, and the auditor tests whether the controls actually operated during that time, so it's much stronger evidence. That's why most enterprise customers ask for a Type 2. One thing I always point out is that it's a report, not a certificate. There's no pass-or-fail badge; the reader has to look at the auditor's opinion, the scope and any exceptions.”

“Good evidence proves the exact control, for the right system, during the audit period. I want it to be reliable, which usually means system-generated: an export straight from the tool with a timestamp, or a screenshot that shows the date, the system name and the settings. It should show who did the action, like the reviewer's sign-off on an access review. And for reports, I want to know how they were produced, the query or filter used, so the auditor can trust the list is complete. Things I'd send back: a screenshot with no date or system visible, a spreadsheet someone has clearly edited by hand, an approval email sent after the change went live, or the policy document offered as proof that a control ran. A policy says what should happen; evidence shows it did.”

“A policy states what the company requires and why, at a high level, and it's approved by leadership. It shouldn't change often. A standard makes it specific and mandatory, for example that admin accounts must use multi-factor authentication or that access is reviewed every quarter. A procedure is the step-by-step how-to that a team follows, like how the service desk grants access. A guideline is advice, recommended but optional. Keeping those layers separate means you don't need board approval every time a setting changes. For an access control policy, I'd write the purpose as something like: to make sure people and systems get only the access they need for their job, that access is approved before it's granted, reviewed regularly, and removed promptly when it's no longer needed. Then the details sit in the access standard and procedures.”

“I'd take the request seriously, because a policy with no way to ask for exceptions just gets ignored. First I'd confirm the facts: is it truly impossible, or could the app sit behind single sign-on, a gateway or a remote access layer that does enforce MFA? Often there's a way. If not, I'd look for compensating controls: only reachable from the internal network or a jump host, fewer users, strong unique passwords, extra monitoring on logins. Then the exception gets written up as a risk, with the business owner's name on it, approved by whoever the policy says can approve exceptions, and with an expiry date tied to a plan to upgrade or replace the app. It goes into the exception register, and I'd review it before it expires rather than letting it roll over automatically.”

“I'm not a lawyer, and details change by country, but most modern privacy laws share the same core. There's the organization that decides why and how personal data is used, called a controller under the GDPR and a data fiduciary under the DPDP Act, and a processor that handles data on its behalf. You need a valid basis for using the data, such as consent, you use it only for the purpose you stated, you collect no more than you need, you keep it no longer than you need, and you protect it. People have rights, like seeing, correcting or deleting their data. And there are breach notification duties; under the GDPR, for example, the regulator must be told without undue delay and, where feasible, within 72 hours. For GRC, that turns into controls: a data inventory, privacy notices, processor contracts, retention schedules and a tested breach procedure.”

“During a SOC 2 audit, an infrastructure lead had missed two deadlines for backup evidence, and when I followed up he said the whole control was pointless. Instead of sending a third reminder, I booked twenty minutes with him. It turned out the request list said 'backup evidence' with no detail, and he thought he had to write a report from scratch. I showed him exactly what the auditor needed, a job history export and one restore test, and an example from last year. He got it to me the next day. On his point about the control, he had a fair argument: the restore test was annual and he wanted it quarterly. I passed that on and we changed it. I did tell him that if it slipped again I'd have to flag it to the audit sponsor, but by then there was no need.”

“In my first year I prepared the evidence pack for a quarterly access review and sent it to the auditors. A day later I noticed the user list I'd attached came from a filter that left out disabled accounts, so it didn't match the population the auditors had asked for. It wasn't a big risk, but it made our evidence look incomplete. I told my manager straight away, then emailed the auditor to say the file was wrong, why, and that the right one would follow that afternoon. I re-ran the report with the filter written down, and had a colleague check it before sending. After that I started adding a short note to every report we sent: the source system, the date it was pulled and the filter used. It saved us questions on later audits too.”

“I try to go to the source first. I follow updates from the standards bodies and the data protection regulators in the places we operate, and I read the actual text or official guidance, not just a summary. For commentary I use a couple of professional newsletters and a GRC community where people share what auditors are really asking about. The harder part is deciding what matters. For each change I ask whether it applies to our industry, our locations, the data we hold and the certifications we keep. If it does, I log it, do a quick gap check against our controls and policies, and turn the gaps into tasks with owners and dates. When ISO 27001 moved to its 2022 version during my last role, that process is how we planned the move to the new control set calmly instead of rushing before the audit.”

“I start by agreeing the scope, say one business unit or one product, and listing the information and systems that matter most, each with a business owner. For each important asset I ask what could go wrong: the threat, the weakness it would use, and what controls already exist. Then I rate likelihood and impact on the company's agreed scale, so everyone scores the same way. That gives me inherent risk before controls and residual risk after them. Anything above the company's risk appetite needs a treatment decision: reduce it with more controls, transfer it through insurance or a contract, avoid it by stopping the activity, or formally accept it. Every risk gets an owner and a due date, goes into the register, and I walk the owners through it for sign-off. Then it's reviewed at least yearly, or sooner after a big change.”

“ISO 27001 has two parts that people often mix up. Clauses 4 to 10 are the management system, and you must meet all of them: understand your context and scope, get leadership commitment, plan by assessing and treating risk, provide resources and awareness, run the processes, measure through internal audit and management review, and improve through corrective action. Annex A is a reference list of controls. In the 2022 version it's grouped into organizational, people, physical and technological themes. You don't pick controls because they're listed; you pick them because your risk assessment says you need them. The Statement of Applicability is the document that joins the two. It lists each Annex A control, says whether it applies, why, and whether it's implemented. For certification, an accredited body does a two-stage audit, then yearly surveillance audits, with recertification every three years.”

“At my last company I was testing our leaver process before an external audit. I took a sample of people who'd left in the last six months and checked whether their accounts were disabled within the time our standard set. Three out of twenty were still active weeks later, all in one sales tool that wasn't connected to the HR system. Before writing anything up, I checked the logs to make sure nobody had used those accounts, and nobody had. Then I went to the IT manager first, showed him the evidence and the pattern, and we agreed it was a gap in the process, not a person failing. He disabled the accounts that day, and we added that tool to the automated leaver workflow. I logged the finding with his response, and when I retested a month later it was clean.”

“First I'd tier it. Customer data and a business-critical service puts it in the high tier, so it gets the full review. I'd ask for independent assurance first, like a SOC 2 Type 2 report or an ISO 27001 certificate with its scope, because that's stronger than a self-filled questionnaire. Then I'd send targeted questions only for the gaps: where the data is stored, encryption, access to our data by their staff, subcontractors, breach history and how they'd notify us. I'd feed any concerns to the business owner as risks with suggested fixes. Then the contract, working with legal: a data processing agreement, breach notification timelines, limits on subcontractors, audit rights and what happens to our data when we leave. Finally, the vendor goes into our inventory with a re-review date, and high-tier vendors get looked at at least yearly.”

“Our marketing team wanted a survey tool that would receive customer email addresses and purchase history. The vendor's security report looked fine on the surface, but when I read the system description, their platform ran on a hosting subcontractor that was left out of the report's scope. When I asked, they confirmed it, and admitted they had no contract terms limiting where that subcontractor stored data. I didn't want to kill the deal, because the tool was a good fit. So I went back to the marketing lead with options. We agreed to send only a customer ID and email, not purchase history, and legal added terms on subcontractors, breach notice and data deletion at the end of the contract. The vendor accepted. Marketing got the tool two weeks later than planned, but with a much smaller risk.”

“My first question is what we told customers when we collected those chats. If the privacy notice said support only, then using them for a new feature is a change of purpose, and under most privacy laws that needs a proper look. So I'd ask: what data is in the logs, since chats often contain names, addresses, even payment details people typed in? Does the feature need personal data at all, or would masked or de-identified text work? Who will have access, where will the data go, and does any vendor get it? How long will it be kept? Then I'd bring in our privacy officer or legal to decide whether we need fresh consent, a notice update or can rely on another basis, and whether a privacy impact assessment is needed. I'd log the outcome so the decision is clear later.”

“First I'd check the facts quietly: the file's version history, the system timestamps, and whether there's any other trace of the review happening on the original date. There may be an innocent reason, like a record copied into a new tool. If it still looks backdated, I would not send it to the auditor. Evidence that misleads an auditor is far worse than a missed control, for the company and for the people involved. I'd take it to my manager or the head of compliance with what I found, not to the whole team. Then the honest route is to treat it as what it is: the review didn't happen on time, so it's a control exception, and we tell the auditor that and show the remediation. I'd also want to understand why the owner felt they had to do it, because that pressure is a problem too.”

“First I'd want to know what we've promised and to whom. Which certifications or reports we hold, which laws apply to our data, what customers have written into contracts, and when the next audit is due. Then I'd look at the current state: the risk register, any open audit findings, the policy set and the control list with owners. I'd pay special attention to overdue remediation, because that's usually where the next audit hurts. And I'd spend a lot of time with control owners in IT, HR and engineering, asking what feels painful about evidence and reviews today. I'd avoid rewriting policies or changing tools in that first month. Once I understand what's working, I can suggest changes that people will actually accept.”

“At my last company, a head of operations didn't see why we needed to spend time on a disaster recovery test for the order system. To him it had never gone down, so it wasn't a real risk. I stopped talking about controls and asked him one question: if the system was down for three days in our busiest month, what would happen? He worked it out himself: orders stuck, customers calling, penalties in two big contracts. Then I showed him that our recovery plan had never been tested and the person who wrote it had left. I gave him two options, a half-day test next quarter or formally accepting the risk with his name on it. He chose the test. It found that one restore step was wrong, which made the point better than anything I'd said.”

“I wouldn't just say no, because accepting risk is a legitimate business choice. But I also can't mark it accepted myself. First I'd make sure we both understand the risk in plain terms and see if there's something quick that lowers it before launch, like turning a feature off or limiting access. Then I'd check our risk policy for who may accept a risk at that level. Often a high risk needs someone more senior than a product head, and sometimes the security leader has to be consulted. If the right person agrees, I'd record it properly: the risk, why it's accepted, any compensating controls, conditions like a fix by a certain date, and an expiry so it gets looked at again. If he's under pressure, I'd offer to help write it up that day so the process doesn't become the delay.”

“The framework's current version has six functions: Govern, Identify, Protect, Detect, Respond and Recover, each broken into categories and subcategories. For a gap assessment I'd first agree the target profile with leadership, meaning which outcomes matter for our size, risks and obligations. Then I'd build the current profile by interviewing control owners and checking evidence, not just asking people to rate themselves. Each subcategory gets a simple maturity score. The gaps between current and target become a roadmap, ranked by risk reduction and effort, with owners and quarters. For leadership, I'd show one page: the score per function now versus target, the top three gaps and what's being done about them. Then I'd re-score every six months so they can see real movement. The framework is voluntary, which is useful, because it lets us shape the target to the business.”

“I'd be honest early, because a promise we can't keep hurts the deal more than a clear plan. A Type 2 report needs the controls to operate over a period that the auditor tests, so starting from nothing, a Type 2 within three months isn't realistic. What might be possible is a readiness assessment to find the gaps, fixing the biggest ones, and then a Type 1 report, which covers design at a point in time. After that, the Type 2 observation period begins. Meanwhile I'd ask sales what the prospect actually needs. Often it's comfort for their own vendor review. We could offer a completed security questionnaire, our key policies, a letter from leadership with the audit timeline, and a call with our security lead. I'd also ask whether the contract could include a commitment to deliver the Type 2 by a set date.”

“I test in two steps. First, design: I walk through the control with the owner and ask whether, if it ran exactly as described, it would actually address the risk. Take a quarterly access review. Does it cover all users, does the reviewer know what they should have, and are removals actually made? If the design is weak, there's no point testing further. Second, operation: did it happen, consistently, across the whole period? For that I don't rely on inquiry alone. I inspect evidence, observe the control or reperform it. Before sampling, I check the population is complete, for example comparing the list of new joiners against HR records. Sample size depends on frequency and the method we follow, so an annual control might be one instance, a quarterly one two, and a daily or many-times-a-day control needs a much bigger sample. Any exception gets written up with a judgement on whether it's a one-off or a pattern.”

“At my last company the acceptable use policy was twelve pages, and nobody had read it. Staff kept asking basic questions, like whether they could use personal cloud storage for work files. I rewrote it with two managers from sales and engineering in the room, because they'd tell me what people really did. We cut it to two pages of clear do and don't rules, and moved the technical details into a separate standard for IT. I got it approved by the leadership team, then we replaced the old annual sign-off with a short quiz using real situations. The biggest sign it worked was that questions to the service desk about file sharing dropped off noticeably, and when we later checked, most people answered the quiz questions correctly without looking. It also passed the next audit with no comments.”

“I'd start by reading the parts that matter, not just the cover. The auditor's opinion, the scope and system description, the report period, and the testing section with the two exceptions and management's response. For each exception I'd ask whether it touches our data or the service we rely on. A missed access review for an internal HR tool is different from failed change control on the production platform. The cloud host being carved out is common, so I'd ask for the host's own report and check it covers the right services. I'd also note the controls the report says customers must run themselves, and make sure we actually do them. If the period ended months ago, I'd ask for a bridge letter. Then I'd give the business a clear answer by the deadline, maybe approve with conditions such as a fix date written into the contract, and record it in the vendor file.”

“First I'd follow our incident plan and pull in the incident lead, security, legal and our privacy officer the same hour, because notification deadlines may be running. My part is less the technical investigation and more making sure we have facts, obligations and a record. I'd check our vendor file for exactly what data we send them and under which contract, so we know the worst case even before they know the details. I'd send the vendor a short written list of questions: what happened, when, which data and customers, whether it's contained, and when we'll get updates. Legal decides whether and when we notify regulators or customers, which depends on the laws that apply, but I'd make sure they have what they need quickly. I'd keep a timeline of every fact and decision. Afterwards, the vendor gets a full re-assessment.”

“I'd split it into three parts. First, contain the exposure. Run a full access review of the finance system now, remove any access that's not justified, and for accounts that shouldn't have had access, check the logs for what they did during the gap. Second, find the root cause. Was there no named owner, did the person leave, was the user report too hard to produce? I'd talk to the people involved rather than assume. Third, fix the control so it can't silently lapse: a named owner and backup, a scheduled reminder, a system-generated user list, and an escalation to the owner's manager if it's overdue. I'd write the management response with dates and owners, and track it in our findings register. The auditor will want to see at least one or two clean quarters of evidence, so I'd plan the retest around that and give leadership a short monthly status until it closes.”

“I think box-ticking starts when people can't see why a control exists. So I try to link every control to a real risk in words the team recognises. An access review isn't for the auditor; it's how we stop a leaver's account being used. Second, I try to cut the wasted effort. If we have ISO 27001, SOC 2 and customer questionnaires, I'd map them to one common set of controls, so an owner provides evidence once, and pull evidence straight from systems where possible. Third, I share outcomes. When testing finds a real gap and it gets fixed, I tell people. And I'm honest when a control isn't adding value, and I suggest changing or removing it. People trust compliance more when they see it can say this one isn't worth it too.”