Internal Controls Design and Effectiveness Testing Questions

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. First prove they overlap by mapping both to the same risk and control objective and listing what each catches that the other does not. Keep the one that is stronger, more reliable and cheaper to evidence, and preserve any unique coverage of the other, either inside the keeper or as a small separate check where the schedules differ. Retire the other only after running them in parallel and re-testing, with the control matrix (the table listing each control, its owner and its test) and anyone relying on the old control updated. Relying means an auditor or regulator is counting on that control as part of their conclusion.

How I decide which to keep

• Coverage: which assets, users and failure modes does each really cover? Overlap is rarely total.
• Strength: preventive beats detective; automated beats manual.
• Reliability and evidence: which produces clean evidence with less effort?
• Cost and false positives: hours per cycle, noise.
• Dependencies: is either named in a contract, regulator mapping or an auditor's reliance?

Example. Control A: monthly, a database lead compares database accounts to the HR roster (detective, finds leavers within about 30 days, ignores whether privileges are appropriate). Control B: quarterly, managers recertify (confirm, one by one, that each person still needs) who has database access and at which privilege level (finds leavers within about 90 days and excess privilege). The overlap is only leaver detection. Comparing effort (illustrative): A takes about 6 hours a month = 72 hours a year; B takes about 20 hours a quarter = 80 hours a year. B runs only quarterly, so folding the roster comparison into B's own cycle would stretch leaver detection from about 30 days to about 90, which is exactly the coverage loss I must avoid. Instead I would keep B as it is and move A's unique check into a small automated roster comparison that runs monthly on its own schedule, costing about 1 hour per run = 12 hours a year. The keeper then costs 80 + 12 = 92 hours a year against 152 hours (72 + 80) for running both. I would keep B, add the monthly roster comparison so the 30-day leaver check survives, run A in parallel for two monthly cycles, then retire A.

Retiring without a gap

1. Write down A's unique coverage and where it moves.
2. Run both in parallel; compare findings.
3. Seed test cases (plant a dummy leaver account on purpose) to confirm the keeper catches them.
4. Update the control matrix, the framework mappings (the table showing which framework requirements, such as ISO 27001 or SOC 2 criteria, each control satisfies) and the next audit scope; tell the assessor (the auditor or reviewer who judges the controls).
5. Keep a rollback: A is not deleted until a clean cycle passes.

Stakeholders and change management. Brief both owners and compliance early, since owners may see a loss of status; announce the date, reason and what changes for them. Success metrics: no missed detection attributable to A's unique coverage, evidence effort in hours per cycle falling (152 to 92 hours a year in the example), exception rate not rising, and manual testing effort reduced. The number of controls in the matrix stays at two in the example, because A's unique check lives on as a small automated one.

Pitfall. Retiring on cost alone, which can quietly remove a control that a regulator explicitly expects.

Direct answer. The excerpt below covers five steps of the access lifecycle in a core application. Each step has a risk, a control objective, one preventive control (stops the problem before it happens), one detective control (finds it afterward), an owner (a role), a frequency and the evidence that it ran. Rules applied: the person who performs a preventive control is never the owner of the detective check on it, and every control has named evidence.

1. Request and approval

• Risk: access granted that nobody authorised.
• Objective: only approved, job-appropriate access is requested.
• Preventive: workflow requires line-manager approval, and application-owner approval for sensitive roles, before provisioning. Owner: Application owner. Frequency: every request. Evidence: ticket with approver, timestamp, role requested.
• Detective: monthly match of newly created accounts and role grants to approved tickets. Owner: IT access governance analyst. Frequency: monthly. Evidence: reconciliation with unmatched items and their resolution.

2. Provisioning

• Risk: granted access differs from what was approved (extra roles, wrong account).
• Objective: access in the system equals the approved request.
• Preventive: provisioning is done from the approved ticket by the identity team, with roles chosen from a fixed catalogue. Owner: Identity and access management lead. Frequency: every request. Evidence: provisioning log linked to ticket.
• Detective: weekly report of role assignments with no linked ticket. Owner: Security operations analyst. Frequency: weekly. Evidence: report and follow-up tickets.

3. Privileged access

• Risk: administrators can change data, configuration or logs without oversight.
• Objective: privileged access is minimal, approved and monitored.
• Preventive: admin roles need approval from the application owner and the security lead, are time-limited, and separate from daily-use accounts. Owner: Security lead. Frequency: every grant. Evidence: approval and expiry date in ticket.
• Detective: monthly review of all privileged accounts and their activity logs. Owner: Head of internal control (not the admins' manager). Frequency: monthly. Evidence: signed review and exceptions.

4. Role change (internal transfer)

• Risk: old access is kept and accumulates.
• Objective: access matches the current role.
• Preventive: an HR transfer event triggers removal of previous-role access and a new request. Owner: HR operations lead with the identity team. Frequency: every transfer. Evidence: HR event, removal log.
• Detective: quarterly access recertification by managers. Owner: Compliance analyst (runs it; managers decide). Frequency: quarterly. Evidence: completed reviews, revocations with dates.

5. Termination

• Risk: leavers retain access.
• Objective: access is removed promptly at departure.
• Preventive: HR termination feeds an automatic account disable; the company policy example here is within 24 hours for standard leavers and immediately for involuntary or privileged leavers. Owner: Identity and access management lead. Frequency: every termination. Evidence: HR date, disable timestamp.
• Detective: weekly comparison of the HR leavers list with active accounts. Owner: IT access governance analyst. Frequency: weekly. Evidence: report and exceptions closed.

Check against the rules. Five steps, five rows, each with one preventive and one detective control, an owner role, a frequency and evidence. In every step the detective owner differs from the preventive owner, and the monthly privileged review is owned outside the admins' own reporting line.

Pitfalls. Controls with no evidence (they cannot be tested), and detective checks run by the same people whose work they review.

Direct answer

IT general controls (ITGCs) are the controls over the technology environment that every application depends on, as opposed to controls inside one application. They usually cover access management, change management, and IT operations (backups, job scheduling, incident handling), and sometimes system development. They matter because automated and report-based controls in the application only work if the code, the configuration and the data are protected from unapproved changes. If the ITGCs are weak, you cannot assume an application control still behaves the way it did when it was tested. Put plainly, you can no longer rely on last quarter's test result (reliance means counting on an earlier test as evidence for today).

Why a weak ITGC undermines the application layer

• Weak change management means code or settings might have changed without approval, so last quarter's test proves little about today.
• Weak privileged access means someone could switch a control off, edit data directly in the database, or alter the logs that would reveal it.
• Weak operations (backup, jobs) means data feeding the control may be incomplete or stale.

Concrete controls and the evidence an assessor would ask for

Case: when I stop trusting an automated control

An enterprise system automatically blocks any purchase order over an approval limit unless a second approver signs. The control tested fine earlier in the year. Then a sample of 25 production changes (the population is every production change in the period; you test a sample drawn from it) shows 9 with no approval record (9 / 25 = 36%), and the same people who deployed also hold database admin rights. Change management is supposed to leave an approval record for every change, so even 1 of 25 would be an exception worth investigating; 36% means it is not working, and no one can show the limit setting was not altered. The earlier test therefore no longer supports reliance (the 9 of 25 here is illustrative).

What I do:

1. Stop relying on the old test result for that control.
2. Re-test the automated control directly for the period, and compare the current configuration and code with the version that was originally tested to see whether it changed. The extent of this re-testing depends on how long the change weakness lasted and how many changes touched the control's code or settings.
3. Look at the change records and logs for the control's settings to find any unauthorised change; extend manual testing of the transactions it was meant to protect.
4. Identify any compensating manual control that independently catches over-limit orders.
5. Remediate the ITGC, run it long enough to test, then restore reliance.

Direct answer. I would not leave the bypass open while the legacy process is rebuilt. I would (1) contain the exposure now, (2) layer temporary compensating controls (alternative controls that meet the same objective as the patch we cannot apply), (3) test that they actually stop or detect the bypass and re-score the risk, and (4) get a time-limited risk acceptance (a formal, signed decision by the people who own the risk to live with it for a set period) signed by the people who own the risk, with a dated plan to fix the legacy process.

Step 1: contain and find out what happened. Check logs for prior use of the bypass. If it was used, this is an incident, not an exception. Cut exposure: restrict network paths to the affected component to the few systems the legacy process needs.

Step 2: compensating controls, in layers.

• Preventive: a virtual patch (for example a rule on a web application firewall or gateway that blocks the exploit pattern), restricted source addresses, removing unneeded privileges on the component.
• Detective: an alert on the specific bypass path, routed to a monitored queue with a response target (illustrative: acknowledged within 15 minutes).
• Corrective: a prepared response plan to isolate the component, and backups that were restore-tested.
  A compensating control must be additional to what already exists and commensurate with the extra risk: a control that was already required does not count. Some regimes formalise this. PCI DSS (the payment card industry standard) has a compensating controls worksheet covering the constraint, objective, added risk, validation and maintenance, and the assessor (the independent, qualified reviewer the company engages to confirm compliance) decides whether it is acceptable.

Step 3: show it reduces risk enough. Residual risk is the risk left after controls; I score it by comparing before and after. Score on a 1-5 likelihood by 1-5 impact scale (bands used here: 1-4 low, 5-14 medium, 15-25 high, so 15 is high):

Impact stays 5 because compromise would be just as damaging; only likelihood moves. The score is a judgment, so I back it with tests: replay the bypass against the protected component and show it is blocked or alerted in every attempt (illustrative test: 10 of 10), and watch health measures (ongoing readings that show the controls still work) such as alert response time (illustrative: median 9 minutes against the 15-minute target), blocked-attempt counts (illustrative: 40 a week, each triaged) and the number of exceptions past their expiry date (target 0). I also note user impact: if the controls add steps for the legacy process users, track ticket volume and failed transactions so the business can see the cost.

Step 4: who signs off.

• The business owner of the legacy process accepts the residual risk (it is theirs), for a fixed period such as 90 days.
• Security leadership (chief information security officer, or delegate) approves that the compensating design is adequate.
• The system owner implements and monitors it.
• Compliance or the external assessor is consulted where a framework requires formal approval of the compensating control.
  A medium residual score still needs sign-off at the level your risk-acceptance policy sets for the pre-patch High.

What would change my call. If testing shows the bypass is still reachable, the system is internet-facing, or exploitation is already seen in the wild, I would shut the process down or force an emergency fix rather than accept the risk.