10 Board Questions About the SOC Every Director Should Ask
A short list of questions that separates a prepared CISO from one who is improvising.
Why the board can no longer delegate these questions
For years, SOC oversight was something boards delegated to the CISO and revisited after an incident. European regulation has closed that option. NIS2 (Directive (EU) 2022/2555), article 20, requires the management body to approve the cybersecurity risk-management measures, oversee their implementation, and follow training to understand them. Members of the management body can be held liable for infringements. DORA (Regulation (EU) 2022/2554) goes further for financial entities: the management body bears final responsibility for managing ICT risk, sets the strategy, and approves the policy on ICT third-party providers.
Oversight is impossible without questions. A director cannot approve risk measures they cannot interrogate. The 10 questions below are deliberately non-technical: they do not require understanding a SIEM rule or an EDR alert. They require understanding maturity, evidence, dependency, cost and accountability. That is board language.
What a good answer always contains. Three elements: a number or a date, the evidence behind it, and the name of the person accountable for moving it. Any answer missing one of the three is an opinion, not an answer.
Questions 1 to 3: maturity and real exposure
1. What is our SOC's maturity on a 0 to 5 scale, assessed by an independent third party?
Why it matters: this is the single number that summarizes everything else, and it anchors the NIS2 approval duty. Why independence matters: the 2026 SOC-CMM data shows self-assessments overestimate maturity by roughly 0.6 points, which is the distance between an adequate SOC and an exposed one. A good answer cites an independent SOC maturity assessment against the SOC-CMM, the score per domain, the date, and the date of the next reassessment.
2. What are the three most material risks the SOC does not cover today?
Why it matters: every SOC has gaps; the danger is a board that believes there are none. A good answer names three concrete gaps (for example, limited visibility of OT networks, no coverage outside business hours, detection coverage of around 60% of relevant ATT&CK techniques, which is the cross-sector average) and states whether each is accepted, transferred or in the improvement plan.
3. How long did it take us to detect and contain a real incident last quarter?
Why it matters: maturity scores describe capability; this question tests whether capability turns into performance. A good answer gives the real figures from the last material incident or exercise, taken from ticket records, not from memory, and compares them against the SOC's own targets and against the NIS2 reporting clock: early warning to the CSIRT or authority within 24 hours, incident notification within 72 hours.
Questions 4 to 6: dependencies and legal obligations
4. If our MSSP failed tomorrow, how long would it take us to operate in-house?
Why it matters: outsourcing transfers operations, never responsibility. DORA makes ICT third-party risk a board-level matter, including exit strategies for critical providers. A good answer states the dependency honestly, points to a documented and tested exit plan, and confirms the organization, not the provider, owns the logs, the use cases and the runbooks.
5. What evidence do we have that runbooks are followed and kept up to date?
Why it matters: a runbook nobody follows is shelfware, and process is where SOCs are weakest. In the 2026 dataset the Process domain averages 2.3 out of 5, below Technology at 2.7. A good answer points to review dates, ticket samples showing the runbook steps were executed, and findings from the last tabletop exercise.
6. Which regulation obliges us to report an incident, and within what deadline?
Why it matters: reporting deadlines are measured in hours and the duty sits with the entity, which means with its management body. A good answer maps the entity's actual obligations (NIS2 timelines, DORA major-incident reporting for financial entities, GDPR's 72 hours for personal data breaches, plus sector and national rules) and shows the contact list and templates exist before they are needed.
Questions 7 and 8: cost and performance
7. What does our SOC cost per year, and how does that compare with our sector?
Why it matters: a board that cannot see the full cost cannot judge whether the SOC is underfunded or inefficient. A good answer presents total cost of ownership: licences, infrastructure, people, the MSSP contract and training, with a qualitative comparison against peers of similar size and regulatory exposure. Precision matters less than completeness; hidden cost is the failure mode.
8. Which three KPIs define SOC success, and which way are they trending?
Why it matters: ten dashboards are noise; three trending indicators are governance. A good answer picks three measures tied to outcomes (for example detection coverage, time to contain, and percentage of incidents handled fully per runbook), shows at least four quarters of trend, and explains any deterioration without defensiveness.
Questions 9 and 10: direction and accountability
9. Which part of the SOC would it be reasonable to outsource, or bring in-house, over the next 12 months?
Why it matters: sourcing is a strategic decision the board should shape, not discover. A good answer is grounded in the maturity matrix: outsource what is commoditized and 24/7, keep in-house what touches business context and crisis decisions, and show the analysis rather than a preference.
10. What is the approved improvement plan, and who is accountable for each item?
Why it matters: under NIS2 the management body approves the measures, so an unapproved or ownerless plan is a direct governance gap. A good answer is a prioritized roadmap derived from the last independent assessment, with an owner, a date and a budget line per item, and a status update at every quarterly review.
What evidence backs each answer
Every question admits a short answer and a long one. The short answer is the number. The long answer is the evidence. This table is the checklist a director, an internal auditor or a supervisor can use to tell the two apart.
| Question | Evidence that defends the answer |
|---|---|
| 1. Maturity score | Independent SOC-CMM assessment report, scores per domain, date |
| 2. Uncovered risks | Coverage analysis (e.g. ATT&CK mapping), risk register entries |
| 3. Detect and contain times | Ticket records from a real incident or measured exercise |
| 4. MSSP dependency | Contract, exit plan, test of the exit plan, log ownership clause |
| 5. Runbooks | Review dates, ticket samples, tabletop findings |
| 6. Reporting duties | Obligation map, authority contact list, notification templates |
| 7. Annual cost | TCO breakdown across licences, people, infrastructure, MSSP |
| 8. Three KPIs | Four quarters of trend data from the SOC's own reporting |
| 9. Sourcing | Maturity matrix analysis per function, options paper |
| 10. Improvement plan | Board-approved roadmap with owner, date and budget per item |
The pattern is deliberate. Eight of the ten evidence items already exist in a SOC that has been through an independent SOC maturity assessment. A board that institutionalizes these questions is not creating work; it is consuming evidence the assessment already produced.
Frequently asked questions
What if the board is not technical?
Better. The 10 questions are deliberately non-technical: they deal with maturity, evidence, dependency, cost and accountability, which is exactly the language of board oversight. The translation into technology is the CISO's job. NIS2 article 20 expects the management body to oversee the answers and to train enough to understand the risks, not to operate the tooling. A director who insists on evidence is doing the job the directive assigns.
How long should the board agenda item on the SOC be?
Twenty to thirty minutes per quarter is enough if the material arrives in advance: the three KPIs with trend, the status of the improvement plan, and any change in the maturity score or in material risks. Add extraordinary time when there has been a material incident, a change of MSSP, or a new independent assessment to approve. The discipline of the quarterly slot matters more than its length.
Are these questions enough for NIS2 article 20 compliance?
They are the oversight half of the duty, not the whole of it. Article 20 requires the management body to approve the cybersecurity risk-management measures, oversee their implementation, and undergo training. The 10 questions operationalize the oversight part and produce documented evidence that it happened, which is what a supervisor will ask to see. The approval part still requires a formal decision on the measures and the improvement plan, ideally anchored to an independent maturity assessment.
Who should answer the questions: the CISO or the MSSP?
The CISO, always. The MSSP can supply data, but accountability cannot be outsourced and a board should never accept a provider reporting on its own performance as the only source. If the CISO cannot answer question 4 or question 8 without the MSSP writing the slide, that is itself a finding about dependency, and worth recording.
How do these questions relate to DORA?
DORA applies the same logic to financial entities with more prescription. The management body bears final responsibility for ICT risk, approves the digital operational resilience strategy and the policy on critical ICT third parties, and the entity must run testing, up to threat-led penetration testing under article 26 for those in scope. Questions 3, 4 and 6 map directly onto DORA's incident reporting, third-party and testing pillars.

Written by
Daute DelgadoCEO & Co-founder, Primedefence
Daute Delgado is CEO and co-founder of Primedefence. He spent more than a decade defending airlines, managed SOCs and international organizations, first as an operator and later leading security teams.
View full profileNeed an independent SOC-CMM assessment?
Book an express diagnostic with a senior assessor. No product sales, no SOC operation.



