Governance & Policy interview questions

Information security governance is the system by which an organisation's security activities are directed and controlled. It makes sure security supports business objectives, risks are managed to an acceptable level and resources are used responsibly.

Typical elements:

• Clear roles and accountability (board, executive sponsor, CISO, risk owners).
• Approved strategy, policies and risk appetite.
• Committees and reporting lines (e.g. a security or risk steering committee).
• Performance measurement and independent assurance.

Frameworks such as COBIT 2019, ISO/IEC 27014 and the Govern function of NIST CSF 2.0 describe governance practices.

The board does not manage security day to day, but it is accountable for oversight. Its role includes:

• Setting or approving risk appetite and strategic priorities.
• Making sure there are adequate resources and clear accountability (e.g. a CISO with access to leadership).
• Receiving regular, business-focused reporting on top risks, incidents and programme progress.
• Challenging management and seeking independent assurance (internal audit, external assessments).
• Understanding regulatory obligations and the organisation's crisis response.

People are both a major source of risk (phishing, mistakes, misuse) and a key control. Governance makes sure:

• Training is mandatory and role-based (e.g. developers, finance, privileged admins).
• Completion and effectiveness are measured (completion rates, phishing simulation trends).
• Policies are acknowledged and consequences for non-compliance are clear.

Most frameworks (ISO 27001, NIST, HIPAA, PCI DSS, SOC 2) include awareness and training requirements.

A policy framework is the structured set of documents that direct security, from high-level intent down to daily steps:

• Top level: an information security policy approved by leadership, stating objectives, scope and commitment (ISO 27001 clause 5.2).
• Topic-specific policies: access control, acceptable use, cryptography, supplier security, incident management, and so on (ISO 27001:2022 control 5.1).
• Standards, procedures and guidelines underneath them.
• Supporting elements: document control (owner, version, review date, approval), a policy library and acknowledgement tracking.

• CISO: leads the security programme, advises leadership and reports on cyber risk.
• DPO (Data Protection Officer): independent adviser on privacy law compliance, required in some cases under GDPR and similar laws.
• Risk owner: the business leader accountable for a risk and its treatment decisions.
• Control owner: the person responsible for operating a control and providing evidence.
• Asset or information owner: decides classification and who may access the asset.
• Internal audit: provides independent assurance to the audit committee.

• Owner: someone accountable for keeping the policy accurate and answering questions about it.
• Review cycle: usually at least annually and after significant changes (new regulation, major incident, reorganisation), as ISO 27001 expects.
• Version control: a change history, approver, effective date and a single published version so staff never follow an old copy.
• Communication: staff must be told about material changes and, for key policies, acknowledge them.

1. Understand drivers: business objectives, risk assessment results, laws, regulations, contracts and frameworks (e.g. ISO 27001, NIST, HIPAA).
2. Benchmark existing documents and identify gaps or overlaps.
3. Draft in clear, concise language — say what is required and who is responsible, not how every tool is configured.
4. Consult stakeholders (IT, legal, HR, privacy, business units) so the policy is realistic.
5. Get formal approval from the right authority (e.g. executive leadership or a governance committee).
6. Communicate and train; make it easy to find.
7. Define exceptions, enforcement and review cycle (commonly at least annually or after significant change).
8. Map the policy to control frameworks so it can be evidenced in audits.

A policy exception process allows justified, temporary deviations without losing control:

• Formal request explaining the business reason, scope and duration.
• Risk assessment of the deviation and any compensating controls.
• Approval by the risk owner at an authority level that matches the risk.
• Recorded in an exception register with an expiry date.
• Periodic review; renewal requires re-justification.

A large number of exceptions against one policy is a signal the policy or standard may need to change.

RACI defines roles for each activity or control:

• Responsible: does the work.
• Accountable: owns the outcome and signs off (only one person).
• Consulted: gives input before decisions.
• Informed: kept up to date.

In GRC, RACIs are used for control ownership, policy maintenance, risk acceptance, incident response and audit preparation.

• A clear charter: purpose, authority, membership, quorum and frequency.
• Cross-functional membership: IT, security, risk, legal, privacy, compliance, business leaders.
• Decision-making authority (e.g. approving policies, accepting risks above a threshold, prioritising investment).
• Good inputs: risk dashboards, KRIs, audit findings, incident trends, project status.
• Minutes and action tracking so decisions are evidenced.
• Escalation path to the executive team or board.

A good cyber risk appetite statement connects the board's attitude to risk with measurable limits:

• Start with qualitative statements by risk category, such as 'We have a very low appetite for risks that could compromise patient safety or the confidentiality of health data.'
• Add measurable tolerances (KRIs with thresholds), such as 'no critical internet-facing vulnerability open longer than 7 days'.
• Define escalation: what happens when a tolerance is breached, and who is told.
• Have it approved by the board and reviewed at least annually.

Different categories can have different appetites. Innovation may be moderate while regulatory compliance is very low.

• Business context: the strategy, growth plans, regulatory landscape and threats.
• Current state vs target state, often measured with a framework such as NIST CSF 2.0 profiles.
• Prioritised initiatives that close the biggest risk gaps, each with an owner, cost, timeline and expected risk reduction.
• A 12–36 month roadmap with quick wins and longer programmes.
• Governance: how progress is measured (KPIs/KRIs) and reported, and when the strategy is revisited.

• Technical enforcement data: for example, the percentage of devices compliant with the encryption standard, read from the MDM tool.
• Control testing and internal audit results.
• Exceptions register: many or long-running exceptions suggest the policy is unrealistic.
• Incidents and near-misses linked to policy breaches.
• Acknowledgement and training completion. These are necessary but weak signals on their own.
• Spot checks and staff interviews during audits.

• The GRC/second line designs the risk and control framework, advises the business, monitors compliance and reports on risk. It is part of management.
• Internal audit (third line) gives independent, objective assurance to the board/audit committee that governance, risk management and controls work, including over the GRC function itself.
• Internal audit should not design or operate the controls it audits, to protect independence.
• The two coordinate (shared risk taxonomy, combined assurance maps) but do not merge.

• Treat repeated renewals as a signal: either the policy is unrealistic, or the risk is being permanently accepted without proper visibility.
• Re-assess the current risk and whether compensating controls still work.
• Ask for a remediation plan with funding. If there is none, convert the exception into a formal risk acceptance at the right authority level.
• Consider whether the policy or standard needs updating for this use case.
• Report long-running exceptions as a metric to the governance committee.

1. Find out how AI is already used (survey, proxy logs, SaaS discovery) and what the business wants to do with it.
2. Bring in legal, privacy, HR, IT and a business representative early.
3. Keep it short and practical: approved tools, prohibited uses, what data can never be entered (patient data, customer PII, source code, secrets), human review of outputs, and how to request a new tool.
4. Align with existing policies (acceptable use, data classification, privacy) and with references such as ISO/IEC 42001 and the NIST AI RMF.
5. Get leadership approval, communicate with examples and plan an early review, because AI changes fast.

• Look at the data first: which emails were clicked, which roles, and whether credentials were actually entered or reported.
• Meet the department head and present the risk in their terms. For example, finance staff with payment authority are prime targets for BEC.
• Change the approach, not just the volume: short role-specific sessions, just-in-time feedback after a click, and recognition for reporting suspicious emails.
• Strengthen technical controls so one click does less damage (phishing-resistant MFA, link rewriting, attachment sandboxing).
• If engagement stays low, report the department's KRI to the governance committee. Leadership accountability is a governance matter.

COBIT (currently COBIT 2019, from ISACA) is a framework for the governance and management of enterprise information and technology. It separates governance objectives (Evaluate, Direct and Monitor) from management objectives and helps align IT with business goals.

ISO/IEC 27001 is a certifiable standard for an Information Security Management System (ISMS) focused specifically on information security risk.

• Scope: COBIT covers all of enterprise IT; ISO 27001 focuses on information security.
• Use: COBIT is often used for IT governance and IT audit; ISO 27001 for building and certifying a security management system.
• They are complementary and are often mapped to each other.

• Map decision rights first: which decisions need committee approval and which can be delegated.
• Use one main risk committee with clear terms of reference, and specialist working groups (AI, data, vendors) that report into it rather than separate decision-making committees.
• Share common tools: one risk taxonomy, one register, one exception process.
• Set thresholds for escalation (for example, high-risk AI use cases or Tier 1 vendors go to the committee; others are approved by the working group).
• Review the model annually and close committees that no longer add value.

The common theme is that management bodies are personally expected to understand and oversee cyber and technology risk:

• NIS2 (EU) requires management bodies of covered entities to approve and oversee cybersecurity risk-management measures and to undergo training, with possible liability for failures.
• DORA (EU financial sector, applicable from January 2025) puts ultimate responsibility for ICT risk management on the management body and requires ICT third-party risk oversight.
• The EU AI Act sets obligations based on AI risk categories, which pushes organisations to inventory and classify their AI systems and to assign accountability.

Governance therefore needs board training, clear accountability, documented approvals and evidence that oversight actually happened.

• Clarify the risk definition first. Often two people are describing different risks that should be split.
• Apply the ownership rule: the owner is the person accountable for the business objective or process most affected and who controls the budget to treat it.
• Facilitate a joint session with the facts: impact, options, cost and timelines.
• If still unresolved, escalate to the risk committee or their common manager to assign ownership. That is what governance is for.
• Record the decision and the rationale in the register.

• Do not answer yes or no. No organisation is fully secure; the honest question is whether risk is within appetite.
• Give a short structured answer: our top risks, where we are within or outside appetite, what has improved, what is still exposed and what we are doing about it.
• Back it with evidence: independent assessments, KRIs, test results (for example ransomware recovery tests).
• End with any decision you need from them.

1. Confirm the integration plan and decision rights: which group policies apply immediately, which local ones remain, and who approves exceptions.
2. Compare the two policy frameworks and control sets (gap analysis), focusing on regulatory obligations that apply only locally, such as local data localisation rules or HIPAA.
3. Merge the risk registers using the group's taxonomy and scoring, and re-rate the top risks.
4. Agree interim controls for network and identity connections between the two companies.
5. Keep certifications valid during the transition. Tell the certification body about significant changes to scope.
6. Communicate clearly to staff which rules apply from which date.