Compliance & Audit interview questions

• Compliance means meeting specific external or internal requirements (laws, standards, contracts, policies) and being able to prove it.
• Security means actually protecting information and systems against threats.

They overlap heavily, but being compliant does not guarantee being secure: requirements are minimum baselines, may lag new threats, and audits sample evidence at a point in time. A risk-based programme uses compliance as a floor, not a ceiling.

• Relevant: directly demonstrates the control requirement.
• Reliable: system-generated or from an independent source is stronger than a screenshot of a spreadsheet.
• Complete: covers the full population and period, not just good examples.
• Timely and dated: shows when the control operated.
• Traceable: you can follow from the population to the sample to the outcome (e.g. ticket → approval → change deployed).

Keep evidence in a central, organised repository mapped to controls.

A gap assessment compares the current state of controls against a target framework or regulation to identify what is missing or insufficient.

• Define scope and the requirements to assess against.
• Gather evidence via interviews, documents and technical review.
• Rate each requirement (e.g. met / partially met / not met).
• Prioritise gaps by risk and effort, and build a roadmap with owners and timelines.

1. Planning: scope, objectives, criteria, risk assessment and audit programme.
2. Fieldwork: interviews, walkthroughs, evidence collection and control testing.
3. Findings: draft observations discussed and validated with management.
4. Reporting: final report with findings, ratings and management responses.
5. Follow-up: tracking corrective actions and validating closure.

Guidance such as ISO 19011 (management system audits) and ISACA's IT audit standards follow a similar structure.

• Internal audit: performed by the organisation's own audit function (or an outsourced provider acting for it), reporting to the audit committee. It covers any area the audit plan prioritises.
• External audit: performed by an independent third party, such as a certification body (ISO 27001), a CPA firm (SOC 2) or a QSA (PCI DSS), against a defined standard, often to give assurance to customers or regulators.
• Internal audits help prepare for external ones but do not replace them.
• Both require independence from the activities audited.

A compensating control is an alternative measure put in place when the primary required control cannot be implemented, which provides a similar level of protection against the same risk.

• It must address the same objective and risk as the original control.
• It should not be a control that is already required anyway.
• It must be documented, justified and tested.
• PCI DSS has a formal compensating-controls worksheet for this in the defined approach.

Sampling means testing a subset of a population (for example 25 of 400 changes) to conclude on the whole population.

• Sample size depends on how often the control runs (annual, quarterly, monthly, weekly, daily, many times a day), the risk, and the confidence the auditor needs.
• Audit firms typically use guidance tables: an annual control may need 1 sample, a daily control around 20–40, and an automated control may need only 1 test plus evidence that change controls protect the configuration.
• Samples should be selected randomly or systematically across the whole period, not chosen by the auditee.
• Any exceptions found must be evaluated, and they may require a larger sample.

• Explain simply: for an auditor, a control without evidence did not happen. Evidence also protects the owner, because it proves they did their job.
• Agree the minimum evidence: who reviewed, what was reviewed, when, what was found and what action was taken.
• Make it easy: a ticket template, a form in the GRC tool or an automated report with an approval step.
• Set reminders in an evidence calendar so collection happens when the control runs, not at audit time.
• Check the first few cycles together.

• Design effectiveness: if the control is performed as described, would it actually address the risk or requirement? Tested through walkthroughs and documentation review.
• Operating effectiveness: did the control actually operate consistently as designed over a period of time? Tested by sampling evidence across the period.

Example: a quarterly access review is well designed if it covers all privileged accounts and requires managers to approve or revoke. It operates effectively if all four quarters were completed, by the right people, and revocations were actioned.

• Inquiry: interviewing control owners (weakest evidence on its own).
• Observation: watching a control being performed.
• Inspection: examining documents, records, configurations, tickets and logs.
• Re-performance: the auditor independently performs the control to check the result.

Auditors usually combine methods and select samples based on control frequency (e.g. more samples for daily controls than for annual ones).

1. Confirm scope, framework/criteria, audit period and key dates with the auditor.
2. Perform a readiness or gap assessment against the requirements.
3. Remediate gaps and collect evidence in advance, mapped to each control.
4. Brief control owners on what to expect and how to answer (honestly, factually, within scope).
5. Set up logistics: single point of contact, request tracker, secure evidence sharing.
6. Track requests and turnaround daily during fieldwork.
7. Review draft findings for accuracy, agree management responses and remediation plans.

• Record each finding with its root cause, risk rating, owner, agreed action and due date.
• Focus on fixing the root cause, not just the instance found.
• Track progress regularly and escalate overdue items through governance.
• Require evidence of closure, and have it validated (by GRC or internal audit) before closing.
• Report trends: open/overdue findings by severity, repeat findings, ageing.

Control mapping links one internal control to the requirements of several frameworks — e.g. a single access review control may satisfy ISO 27001 Annex A, SOC 2, HIPAA Security Rule, PCI DSS and NIST 800-53 requirements.

A unified (common) control framework is a single set of internal controls mapped to all applicable frameworks.

• Test once, comply many.
• Reduces audit fatigue for control owners.
• Makes it easier to add a new framework or regulation (e.g. a new national requirement) by mapping instead of starting over.

Publicly available crosswalks (e.g. NIST's online mappings) can help, but mappings should be reviewed by people who understand the context.

Before relying on a sample, the auditor needs confidence that the population (the full list of items, such as all leavers or all changes) is complete and accurate. This is often called IPE: information produced by the entity.

• They check the source system, the query or report used, filters and parameters, and compare totals with another source.
• A screenshot of the query and parameters, or the auditor watching the report run, is common evidence.
• If the population is incomplete, every test based on it is unreliable.

A good finding has five elements, often called the 5 Cs:

• Criteria: what should be happening, meaning the policy, standard or requirement.
• Condition: what was actually found, with facts and numbers.
• Cause: why it happened (root cause, not just a symptom).
• Consequence: the risk or impact to the business.
• Corrective action: the recommendation for what should be done.

Add a risk rating and agree the facts with management before issuing.

Root cause analysis (RCA) finds the underlying reason a problem happened so it can be fixed permanently, rather than fixing only the symptom.

• 5 Whys: keep asking 'why' until you reach a process or design cause.
• Fishbone (Ishikawa) diagram: group possible causes into people, process, technology, environment, and so on.
• Timeline analysis: for incidents and repeated failures.
• A good root cause is something you can act on, such as a missing process, unclear ownership or a design flaw. 'Human error' alone is rarely the real root cause.

• Be honest. Never create or back-date evidence. Fabricated evidence is far worse than a gap.
• Clarify exactly what the auditor needs. Sometimes alternative evidence exists, such as system logs, tickets or meeting minutes.
• If the control did not operate, say so, explain any compensating controls and share the remediation plan.
• Agree a timeline for anything that can legitimately be provided later.
• Afterwards, fix the evidence process so the gap does not happen again (evidence calendar, automated capture).

• Build one combined audit calendar and avoid overlapping fieldwork weeks for the same teams.
• Use your unified control framework: collect evidence once and reuse it across audits.
• Create a single evidence repository with clear naming and dates.
• Prepare control owners: brief them on what each auditor will ask and when.
• For the customer audit, offer existing reports (SOC 2, ISO certificate) first to reduce scope.
• Hold a short daily stand-up during fieldwork to clear requests quickly.

• Treat repeat findings as a governance issue, not just a technical one. Report it to the risk or audit committee with its history.
• Do a proper root cause analysis. Previous fixes probably addressed symptoms (one-off clean-ups) rather than the process.
• Assign a senior owner with authority and budget, and break the fix into milestones with dates.
• Validate closure with testing over a period, not just a single point in time.
• Add a KRI so drift is visible before the next audit.

CCM uses automation to test controls continuously or frequently instead of only during annual audits. Examples:

• Automated checks of cloud configuration against benchmarks.
• Daily comparison of HR leavers with active accounts.
• Alerts when endpoints are missing encryption or EDR.
• GRC platform integrations that pull evidence directly from source systems.

Benefits: earlier detection of control failures, less manual evidence collection, and a more accurate real-time compliance posture.

• Certification: an accredited certification body confirms that a management system conforms to a standard and issues a certificate, usually valid for 3 years with surveillance audits.
• Attestation: an independent CPA firm issues an opinion on management's description and controls against criteria, such as the Trust Services Criteria for SOC 2. The output is a detailed report, not a certificate.
• A SOC 2 report shows tests and results, including exceptions. An ISO certificate shows that the scope is certified without control-level test details.
• Customers often want both: the certificate for the management system and the SOC 2 report for control detail.

• Fix the process before you automate it. A tool will not fix unclear ownership or a messy control library.
• Start with a unified control set and clear data model (risks, controls, assets, vendors, evidence).
• Prioritise high-volume, repetitive work: evidence collection through integrations (cloud, identity, ticketing), questionnaires and reminders.
• Phase the rollout: one framework or module first, measure the time saved, then expand.
• Plan adoption: training, dashboards people actually use, and executive sponsorship.
• Keep exports and data ownership in mind to avoid vendor lock-in.

1. Log it, confirm the exact deadline and inform legal and compliance leadership immediately.
2. Clarify the scope. If anything is ambiguous, ask the regulator early and in writing.
3. Assign owners for each item and a single coordinator. All communication goes through the agreed channel.
4. Gather evidence, review it for accuracy and consistency, and have legal review the response before it is sent.
5. If the deadline cannot be met for some items, request an extension early with a reason.
6. Keep a complete record of what was sent and when, and track any follow-up commitments.

• Fix it immediately and confirm the control works again.
• Assess the impact of the gap: what activity went unmonitored, and could an incident have been missed? Review other sources for that period if possible.
• Record it as an issue or deficiency, and tell the right people: the risk owner and, if it affects an audit period, the auditor.
• Do a root cause analysis. Why did nothing alert you? Add monitoring of the control itself (for example, an alert when log volume drops).
• Update the risk assessment and consider whether customers or regulators must be informed, based on contracts and law.