Governance & Compliance interview questions
Governance & Compliance questions a Cybersecurity can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A debug log prints the full request body, including national id. What do you do?
The strongest answer: Stop it, purge what policy requires, and log a redacted shape — I do not keep “just this week” of real identifiers
Why it works: Exactly. Logs leak. Redact at source. Internal is still a copy.
- Redact at source.
- Purge what you already wrote.
- Internal ≠ safe.
- Do not MD5 an id and relax.
An auditor asks if you “do MFA.” What do you show?
The strongest answer: The control as it runs — who is enrolled, who is excepted, and a log that it challenged a sign-in — not a policy PDF that says we value MFA
Why it works: Exactly. Compliance is evidence of the running control. Slides are not evidence.
- Show the running control.
- Show exceptions.
- Show a real challenge log.
- Do not hand a slogan.
What does GDPR ask of you as an engineer, in practical terms?
The strongest answer: Collect personal data for a stated purpose and no more, keep it only as long as you need it, be able to find, export and delete one person’s data, and keep it secure — design decisions, not just a policy page
Why it works: Right — purpose, minimisation, retention, access and security are the parts that turn into schema, jobs and code.
- Purpose, minimisation, retention.
- Know where personal data lives.
- Be able to export and delete.
- It follows the person, not the server.
What does “we encrypt at rest” look like as evidence?
The strongest answer: A control you can show: key owner, algorithm, and a sample volume or field that is actually encrypted — not a policy sentence
Why it works: Exactly. Evidence is the running control. Locked rooms and pitch decks are not encryption.
- Show key, algo, and a real volume.
- Name the owner.
- Decks are not evidence.
- A room is not at-rest encryption.
One customer asks for ISO 27001 and another asks for SOC 2. What is the difference, and what does each ask of engineering?
The strongest answer: ISO 27001 certifies a management system — scope, risk assessment, controls, continual improvement; SOC 2 is an auditor’s report on whether controls met the trust criteria, usually across a period. Both want evidence that controls actually ran
Why it works: Right — and the engineering cost is the same in both: evidence the system produces, not screenshots gathered in a rush.
- ISO certifies a system; SOC 2 reports.
- Both want evidence over time.
- Map controls once, reuse evidence.
- Automate evidence, not screenshots.
How do you stop PII from returning to logs after one purge?
The strongest answer: A pipeline test, a field catalogue, and a default deny on new request dumps — plus retention that matches the policy, not “forever for debug”
Why it works: Exactly. Tests and defaults. Colder storage of the same PII is still PII.
- Test the pipeline.
- Catalogue fields.
- Default-deny dumps.
- Retention ≠ colder PII forever.
A control is “required by SOC 2.” What do you map it to internally?
The strongest answer: A running owner, a system of record, and the evidence it emits — the framework is a lens, not a second set of work you invent in a spreadsheet
Why it works: Exactly. Map the framework to what you already run. Shadow checklists are how audits become theatre.
- Owner + system + evidence.
- Framework is a lens.
- No shadow checklists.
- No screenshot drawers.
A squad wants a vuln exception “until after launch.” What do you require?
The strongest answer: A named risk owner, a residual, and an expiry — exceptions without clocks become the architecture
Why it works: Exactly. Time-boxed, owned, written. Thumbs-up and permanence are how exceptions become the product.
- Owner + residual + expiry.
- Write it down.
- No emoji accepts.
- No silent forever.
Why bother classifying data if “we encrypt everything”?
The strongest answer: So retention, access, and logging match the blast radius — encryption is one control; a public blog and a national-id field are not the same pile
Why it works: Exactly. Class drives who sees, how long, and what we log. Encrypt-everything is necessary and not a policy.
- Class drives access and retention.
- Encryption is one control.
- Blog ≠ national id.
- Do not refuse-all as a substitute.
You are asked for a two-year security strategy. What are the first three pages?
The strongest answer: The risks you owe (identity, money, data), the paved road (SSO, secrets, patches), and the evidence you will show — not a tool catalogue
Why it works: Exactly. Risks, road, evidence. Tools and empire are appendices.
- Name the risks you owe.
- Describe the paved road.
- Say what evidence you will emit.
- Put tools in the back.
What does an honest risk register refuse to do?
The strongest answer: Invent a precise “expected loss” you cannot defend, or hide a risk because it is embarrassing — it names owner, residual, and review date
Why it works: Exactly. Owners and residuals. Fake precision and hidden rows are how you lose the next incident review.
- Owner, residual, date.
- No invented precision.
- Do not hide embarrassing rows.
- Work happens off a living list.
How do you stop compliance from becoming a second company?
The strongest answer: Map every ask to a running control and reuse the artefact — auditors see what operators see, not a parallel universe of screenshots
Why it works: Exactly. One system of record. Binders and disconnected GRC are a second company.
- One running control per ask.
- Reuse operator artefacts.
- No binder company.
- GRC must connect.
What do you take to the board, and what do you refuse to invent?
The strongest answer: Patch SLA on internet assets, MFA coverage, time-to-contain, and named residuals — not a “risk score” you made up or a percentile of breaches prevented
Why it works: Exactly. Operable metrics and residuals. Invented ranks and peer percentiles are honesty violations.
- SLA, MFA, contain time, residuals.
- No homemade risk score.
- No invented percentiles.
- Owners on incidents.
A vendor will see customer PII. What is the security review actually for?
The strongest answer: Where the data goes, who can access it, how they notify, and how we leave — a questionnaire score without those four is a sticker
Why it works: Exactly. Data path, access, notify, exit. Certificates are inputs. Hope is not a review.
- Data path and access.
- Notify and exit.
- Certificates are inputs.
- Legal + technical.
A product wants to keep “all events forever” for later. What do you require?
The strongest answer: A purpose, a retention, and a deletion path — collection is not a hobby, and “later” is not a lawful basis you invent in the room
Why it works: Exactly. Purpose and a clock. Someday-anonymise and pre-ticked banners are how you fail a privacy review.
- Purpose + retention + delete.
- No hobby collection.
- No someday-anonymise.
- No pre-ticked consent.
You are building a security programme from nothing. How do you use a framework such as the NIST Cybersecurity Framework without it becoming a paper exercise?
The strongest answer: As a map of the functions a programme must cover — govern, identify, protect, detect, respond and recover — to find what we do not do at all, then let our real risks choose which few gaps get funded this year
Why it works: Right — coverage first, then risk-based selection. The framework tells you what you forgot, not what matters most here.
- Use the framework as a map.
- Find what you do not do at all.
- Let risk pick the gaps.
- Refuse uniform maturity targets.
Exceptions are how the company ships. What do you change first?
The strongest answer: Publish the exception rate next to delivery, expire the oldest, and staff the paved road that made people ask — do not start with a shame list
Why it works: Exactly. Visibility plus a better road. Shame, freezes, and hidden books are how shadows grow.
- Publish the rate.
- Expire the oldest.
- Fund the road.
- No shame list, no hidden book.