Internal Controls Design and Effectiveness Testing Questions

Direct answer. A control should be owned by the person who runs the business or technical process the control sits in (for example the engineering manager whose team deploys code), not by the security team and not by the auditor. The reason: only the person who can change how the process runs can fix a failing control. The security team can advise and test, and an auditor who owned the control would be marking their own work. The owner is accountable for the control operating every time and for fixing it when it does not. Ownership must survive people and systems changing, and rubber-stamping is caught by testing whether the control ever actually stops anything.

What I expect from an owner

• Operate the control, or delegate it by name and stay accountable.
• Keep evidence as a by-product of the work (a ticket, a log, a signed review), not rebuilt before an audit. For a code-review control that means pull request records showing the author, a different reviewer and timestamps, plus the pipeline log of what was deployed.
• Review exceptions and failures, and raise them instead of absorbing them.
• Tell GRC (governance, risk and compliance) before changing the process or system the control depends on.
• Not be the only person who tests their own control (self-review is weak assurance, meaning it gives little confidence that the control works; a second-line risk or GRC team, or internal audit, should also test it).

When the owner leaves or the system changes

• Record the owner in the control matrix (the table listing every control with its risk, owner and test) as a role plus a named person, with a named backup.
• Trigger a handover from the HR leaver or transfer event. An unowned control is an "orphan"; a quarterly check lists controls whose owner no longer appears in the directory and reassigns them within a set number of days (illustrative: 10 business days).
• Tie system changes (migration, new tool, new vendor) to change management (the formal process for approving and recording changes): the change ticket asks "which controls run on this?" and the owner re-confirms design before cutover, then the control is retested once after the change.

Spotting rubber-stamping
Warning signs: approvals in seconds, a 100% approval rate with no revocations ever, one reviewer approving in bulk, no comments, a reviewer who cannot explain what they approved.

Example: a quarterly access review (a manager confirms who still needs which access) shows a manager approved 412 of 412 entitlements (the individual permissions held by accounts) in 6 minutes, which is under a second per item. "Approved" here means the manager chose to keep the access rather than revoke it. I would plant five known-inappropriate accounts (with the system owner's agreement, so nobody mistakes them for a real incident and they are removed afterwards) before the next cycle. If all five are approved, the control operates on paper only. Then I would reperform a sample independently (redo the review's work myself on a sample and compare my answer with the reviewer's) and check whether any reviewer ever changed anything.

Trade-off. Strong ownership needs authority and time. If the owner is junior or overloaded, the control degrades quietly, so I would escalate the load rather than pick a more compliant-looking name.

Direct answer. A compensating control is a substitute control used when a real constraint stops you meeting a requirement as written. It is legitimate when that constraint is genuine and documented (technical or business, not mere cost or convenience), and the substitute provides at least equivalent protection against the same risk, is documented and owned, and is tested over time. A workaround skips that analysis: it is convenient, undocumented and never reviewed.

What makes it legitimate (and what an assessor needs to see)

1. A real, documented constraint: a technical or business limit, not cost or inconvenience alone.
2. Meets the intent of the original and gives a similar level of defence against the same risk (PCI DSS, the Payment Card Industry Data Security Standard that governs organisations handling card payments, states this in its Appendix B on compensating controls).
3. Above and beyond other requirements: meeting other requirements anyway does not count as compensation.
4. Addresses the extra risk created by not meeting the requirement as written.
5. Documented residual risk (the exposure left after the substitute), an owner, and approval.
6. An expiry or review date and ongoing tests to show it keeps working.
7. Not retroactive: it cannot cover a task that should have been done and was not; it is a planned substitute in place before the assessment, not a way to excuse a past miss.

Example. A fleet of legacy handheld scanners cannot support encryption of data stored on the device (the requirement: protect data at rest, meaning data sitting in storage rather than moving across a network). Compensating controls: the app is reconfigured so no sensitive data is kept on the device (only a token, a meaningless stand-in value that maps to the real card number held in a secure system elsewhere), devices are on an isolated network that reaches one server, locked in a cabinet outside use, and enrolled for remote wipe (the ability to erase a lost device's contents over the network). The assessor (the qualified reviewer who decides whether the substitute is accepted) gets the constraint statement, the risk analysis, test evidence (a check that no data is left after use), owner and a review date tied to the device replacement plan.

Workaround, by contrast: "we turned off the check because the old device could not do it" with no replacement control, owner or date.

Pitfall. Using compensating controls to avoid fixing the underlying system forever.

Direct answer. A compensating control is a substitute control used when a real constraint stops you meeting a requirement as written; it must give equivalent protection against the same risk. Here the legacy app cannot support MFA (multi-factor authentication, a second proof of identity beyond the password), so I would put the strong authentication in front of the legacy app instead of inside it: isolate the app on its own network segment (a separate part of the network behind firewall rules), allow access only through a privileged-access gateway or jump host (a hardened intermediate server that administrators must log into first, which enforces MFA), and add session recording, just-in-time (JIT) privileged access and frequent access reviews. Then I would show these controls meet the intent of the MFA requirement, record the residual risk and test them regularly with an expiry date.

Controls I would propose
Items 1 and 2 close the attack path the MFA requirement guards; items 3 to 7 limit and monitor what is left.

1. Network isolation: the app sits in its own segment; firewall rules permit only the jump host.
2. Jump host with MFA: users authenticate with MFA to the gateway, then reach the app. The protocol limitation is bypassed rather than argued with.
3. JIT privilege: admin rights granted for a short window with approval, not standing.
4. Credential vaulting and rotation (a password vault stores the app's credentials and changes them regularly) for app passwords, so shared or static credentials are not memorised.
5. Session monitoring: record privileged sessions and alert on unusual use (outside hours, new source).
6. Access review cadence: quarterly review of who can reach the app (monthly for admins).
7. Residual risk: document what remains, meaning the exposure left after the controls (for example an attacker already on the jump host after MFA, weak in-app audit logs), and have the risk owner accept it in writing.

Showing sufficiency. State the objective of the requirement: a stolen or guessed password alone must not be enough. Map the attack path: attacker needs the network path (blocked) and the MFA factor (at gateway). The controls must go beyond what is already required elsewhere; counting existing controls is not compensation. For PCI DSS (the Payment Card Industry Data Security Standard, the rules for organisations handling card payments) this follows its formal compensating-control rules: a legitimate documented constraint, equivalent defence, above and beyond other requirements, and a worksheet (the compensating controls worksheet in PCI DSS Appendix C), which in outline asks for the constraint, the original requirement's objective, the added risk, how the substitute meets the objective, how it was validated and how it is maintained. Whether an assessor accepts it is the assessor's decision.

Document and test over time

• Design test now (is the control, as designed, capable of meeting the objective): walk through the firewall rules and gateway config.
• Operating tests (does it actually run as designed over time): quarterly connectivity test from a non-jump subnet (must fail); review a sample of recorded sessions; check the access review happened.
• Set an expiry or annual review date and a retirement plan (replace or upgrade the app).

Pitfall. Treating a compensating control as permanent. It is a time-limited bridge.

Direct answer. I would track a small set of control-health measures every month instead of relying on the yearly test: coverage, timeliness, effectiveness, freshness, plus exceptions and incidents. Baseline them over the first two or three periods of data, then watch trends and tolerance bands. Quiet degradation shows up as shrinking coverage, exception creep, late evidence and suspicious silence.

What to measure (per important control)
If I could show only three first: coverage (how much is protected), timeliness (how fast the control acts) and the pass rate of an independent test (whether it works when checked). The rows below add detail.

Baseline. Measure for two or three periods before setting thresholds, because one period can be unusual (a holiday, a patch window) while a few show what normal looks like and how much it naturally varies. Anchor with an independent sample test so the numbers are checked against reality. Set green, amber and red bands (tolerance bands: the ranges that say fine, watch, and act) by risk tier. Illustrative bands for EDR coverage of a high-risk tier: green at 98% or more, amber from 95% up to 98%, red below 95%. Red triggers action at once; a worse reading inside green or amber triggers action after two consecutive worse periods, because one dip can be noise and two is a trend.

Detective controls (logging and alerts). Track log-source coverage, alert-to-triage time, and results of seeded detection tests (a planted harmless event that should alert). Findings and failures go into the risk register (the list of risks with owners and ratings) so residual risk (the exposure left after controls) is re-scored when a control gets weaker.

Worked example of hidden degradation. EDR covers 1,900 of 2,000 servers = 95.0% (amber in the bands above). Next quarter the estate grows to 2,100 and 1,950 are covered: 92.9%. The count of protected servers went up by 50 but coverage fell by 2.1 percentage points (92.9%, now red) because the denominator, the total number of servers you divide by, grew. A count dashboard would say "better".

Other signs of a decaying control: the control owner changed without handover; alert volume drops to zero (silence is not safety); detection tests start failing; manual overrides rise; evidence is collected late.

Reporting. Give leadership 6 to 8 measures with trend and owner, starting with the three above, and say which are independently verified.

Direct answer

I would not answer the board until I had established three things from evidence: whether the control, working exactly as written, would have stopped or caught this event (a design question), whether it actually ran as written when the event happened (an operating question), and what decision originally set its strength. Then I would report the cause plainly, show the earlier decision was or was not reasonable with the information available, and assign corrective actions with named owners.

Step 1: Preserve evidence and build a timeline

Secure logs, configuration history, tickets and alerts first. Build a timeline: when the control was designed, last changed, last tested, and what it did during the incident.

Step 2: Design or operation?

Both can be true, and the fix differs: design failures need a redesigned control, operating failures need ownership, monitoring and enforcement.

Illustrative example. The control said "every server in the asset inventory runs an endpoint-protection agent". 17 of 212 inventoried servers had no agent, so 195 of 212 were covered (about 8.0% not covered): an operating failure. But the compromised host was not in the inventory at all, so the written control could never have covered it: a design failure as well.

Step 3: Evidence to gather

• The control description and its owner of record
• Configuration and change history around the incident
• The control's own logs, alert records and any exceptions granted
• Previous test results and findings, and whether remediation was closed
• The original risk assessment and any risk-acceptance record

Step 4: Document the earlier decision to accept that level of control

Reconstruct the decision record: the risk as understood then, the options considered, their cost, the residual risk (what remained after the chosen control), who approved it, and the date it should have been revisited. Judge the decision against what was known at the time, not hindsight, and say so in the write-up. If no record exists, state that fact; do not create one after the event. A missing record, or an acceptance with no review date, is itself a governance finding. Risk acceptance means a named person formally agreeing to live with a risk instead of reducing it further. Who may accept risk is set by your risk appetite (how much risk the organization will take) and delegations (the written limits on what each role may approve, for example a team lead up to a low rating, a director up to medium, only the executive committee above that). A governance finding is a weakness in how decisions are made and tracked, as opposed to a weakness in a technical setting. Illustrative record: Risk R-14, servers without endpoint protection, rated medium. Option chosen: agent on inventoried servers only; cloud-account discovery deferred (cost). Residual risk: medium-low. Approved by: Head of Infrastructure, within delegation. Review by: 30 June.

Step 5: Corrective and preventive actions (CAPA)

• Corrective: fix this instance (install agents on the 17 servers, add the missed host to inventory).
• Preventive: change the cause (discover assets from the cloud account, not from a hand-kept list; alert when coverage drops below a stated level; set an expiry on risk acceptances).
• Ownership: one accountable owner per control plus a named backup, and a metric reviewed on a schedule (for example, agent coverage: servers with a working agent divided by servers found by cloud-account discovery, reviewed weekly. In the example above, if discovery had found the 212 listed servers plus the one unlisted compromised host, 195 / 213 is 91.5% (the inventory-only figure, 195 / 212, is 92.0% and would have hidden the unlisted host), against a stated floor of 98%, which would have raised an alert; discovery may of course find more than one unlisted host, which would lower the figure further).
• Verify the fix with a reperformance test after remediation.

What goes to the board

Plain cause, whether the decision was reasonable at the time, what changes, who owns each change, and when it will be verified. Illustrative wording: "The endpoint control was designed to cover only servers in the inventory. One compromised server was not in the inventory, so the control could not have protected it; separately, 17 of 212 listed servers had no agent. The 2025 decision to cover inventoried servers only was within the approver's delegation and based on the information then available. We are adding automatic discovery, assigning one named owner and a backup, and will re-test in six months. Evidence is preserved." Legal and the incident lead decide what is shared externally.

Pitfalls and what would change my call

• Blaming an individual when the process lacked a coverage check.
• Declaring "design failure" to excuse the owner, or "operating failure" to avoid funding a redesign: the evidence decides.
• If the original decision was documented and reasonable, the finding becomes a review-cadence gap, not negligence.