Internal Controls Design and Effectiveness Testing Questions

Direct answer

A control is a safeguard that reduces a risk. A preventive control stops the bad event from happening (a blocked action), a detective control notices that it happened or is happening (an alert or a review), and a corrective control limits the damage and restores the good state afterwards (a rollback or a restore). I choose the mix by how bad and how reversible the harm is, and I distrust any "preventive" label until someone has tried and failed to get around the control.

What each type looks like on a cloud customer-facing app

The same split exists outside IT. In payments, requiring a second approver before money is released is preventive and manual; a monthly reconciliation review (comparing two records and investigating differences) is detective. For site reliability engineering (SRE), a deploy gate that blocks a release failing health checks is preventive, an alert on error-rate burn (errors using up the service's allowed failure budget faster than planned) is detective, and an automatic rollback is corrective. They complement each other: prevention lowers how often you need detection, detection triggers correction, and correction shortens how long a miss hurts.

How I decide the mix

1. Rank what could go wrong by impact and reversibility. Data exposure cannot be undone, so it gets strong preventive controls. A slow page can be fixed in minutes, so detection plus fast rollback is cheaper than blocking every change.
2. Ask how quickly I would find out. If detection is slow or blind, I push harder on prevention.
3. Weigh cost: preventive controls add friction for engineers, so I place them where the harm justifies it.
4. Decide with partial information: assume some failures will get through and some detections will be missed, so keep at least two layers for anything high impact, and name the response step (the specific person who acts in the first hour, for example who isolates the system, who rolls back, who informs customers). That step is what turns a detective alert into a corrective action.
5. Prefer automated over manual where possible: a manual control depends on a person remembering, so I check how often it runs and what happens on holiday weeks.

A compensating control is a substitute used when the intended control cannot be applied; its effectiveness is shown by testing it over time, not by describing it. Example: a legacy system cannot support multi-factor sign-in, so admins may only reach it through a hardened jump host (a locked-down gateway machine) with session recording and a weekly review of the recordings.

Why I would distrust a "preventive" label

• It can be bypassed: an admin override, a break-glass path (a pre-approved emergency admin route that skips the normal checks) nobody reviews, or a "warn only" mode left on.
• It covers new resources but not the old ones, or only some accounts.
• It is manual and relies on a person, so it is really a hope.
• It has never been tested with a negative test (deliberately try the forbidden action and confirm it is refused).
• The people it constrains can edit it.

Example: a rule says "no public storage buckets". I try to create one in a test account. If it succeeds, or if existing buckets were never checked, the label was wrong and the control is at best detective.

Direct answer

Segregation of duties (SoD, also called separation of duties) means no single person can complete a sensitive process end to end without someone else's involvement. It matters because one person who can both do something and approve or hide it can cause an error or fraud that nobody catches, and because a single compromised account then has too much reach. I enforce it with tools wherever I can, and where I cannot, I substitute an independent review that someone else operates.

Where conflicts show up in IT and security

• A developer who writes code, approves their own pull request and deploys it to production.
• An administrator who approves their own access request, or grants access and also reviews who has it.
• A database administrator who can change data and also delete the audit logs of that change.
• A security analyst who closes the alerts that concern their own team's systems.
• One person who both creates and approves a firewall rule or a cloud permission change.

How to enforce it

1. Make the tool enforce it. Require an approver different from the author on code merges (branch protection is a repository setting that blocks a merge until a second person approves), and let only the deployment pipeline's identity write to production, not individual developers.
2. Split the roles in the access workflow: the requester, the approver and the person who provisions are three different identities.
3. Use separate admin accounts and time-limited elevation instead of standing admin rights.
4. Send logs to a place the people being logged cannot edit or delete (tamper-resistant logs, for example write-once storage), so a record of what they did survives.
5. Run a periodic access review that checks for toxic combinations: pairs of permissions one person must not hold together (for example, "create vendor" plus "approve payment"). Run it step by step: export every account with its permissions, flag anyone holding both halves of a toxic pair (illustrative: 3 flagged out of 400 accounts), ask each flagged person's manager to remove one permission or document why both are needed, then re-export to confirm the pair is gone.

NIST SP 800-53 Revision 5 (a US government catalogue of security controls) lists this as control AC-5, Separation of Duties.

Where it cannot be fully enforced

On a small team the same people have to do both jobs. Then use compensating controls: every change gets an after-the-fact review by someone outside the conflict, break-glass access (an emergency override) raises an alert and needs a written reason, and all privileged actions land in tamper-resistant logs. Record the residual risk (the exposure that remains after the controls), mainly collusion (two people deliberately working together to get around the control), and have the risk owner (the manager accountable for that area) accept it in writing.

Worked case: a six-person team where everyone can deploy. Keep that, but enforce a different reviewer on each merge and send a weekly list of all production changes to the engineering manager, who checks each against a ticket. The conflict is not removed; it is made visible to someone independent.

Direct answer

A requirement such as "restrict access to sensitive data" is a goal, not a control. First write a control objective (a plain statement of the outcome a set of controls must achieve), then pick controls (specific activities or technical mechanisms that each reduce part of the risk), then give each control its own test. There is no fixed number of controls: it takes as many as it needs to close every way the objective could fail. For the example below, seven, of which only some are technical: C2, C4 and C6 are technical mechanisms (software or network settings), C3 is a mix of a technical permission and a human approval, and C1, C5 and C7 are mostly procedural (people following a process). A requirement usually needs both kinds, because a technical control with no process to keep it accurate decays.

Step 1: Turn the requirement into an objective

Requirement: "restrict access to sensitive data". Objective (illustrative): Only authenticated, authorized people and services can read or change customer personal data in the production database, access is removed when no longer needed, and inappropriate access is detected. Good objectives say who, what, and what failure looks like, so they can be tested.

Step 2: Ask how the objective could fail, then add a control for each gap

Preventive controls stop the event, detective controls notice it after the fact, corrective controls fix what was found. Count check: 7 rows, C1 to C7.

Step 3: Many-to-many mapping

One objective maps to many controls (here, all seven), and one control can serve many objectives. C2 also supports an objective like "administrative actions are attributable to a person". Keep this mapping in a control matrix (a table linking each control to its objective, risk, owner, and requirement), so a change to one control shows what it affects. One filled-in row (illustrative): C5 | Quarterly review of who holds access | objective: only authorized people can read customer personal data | risk: access accumulates after role changes | type: detective | control owner (the person accountable for the control working): Head of Platform | data owner (the person who decides who may use the data): Director of Customer Data | requirement: the client contract's access clause | evidence (the records that prove the control ran): the signed review sheet for each quarter, with the removal tickets it raised.

Step 4: Test each control two ways

Design test: if the control operates exactly as written, would it meet its part of the objective? Operating test: did it actually run, consistently, over the period? When a control runs many times, you cannot check every run, so you take a sample: a small set of items drawn from the population, which is every occurrence of the control in the period. For example (illustrative), if 240 access grants were made in the quarter, the population is those 240 grants, and a test plan might pick 25 at random (so no one chooses only the tidy ones) and trace each to its approval. The size and method come from your test plan or auditor.

Trade-offs and pitfalls

• Stopping at C2 and C3 is the common weak answer: nothing then detects access that drifts over time.
• A control with no test is an assumption. Automated controls (C2, C4) are cheap to re-test; manual ones (C3, C5, C7) need samples and evidence.
• More controls is not better. Each one costs owner time, so drop a control whose risk another already covers.
• A framework or auditor may require specific controls; where it does, take their list as a floor and ask them to confirm.

Direct answer. Automating the quarterly access review gains completeness (every account, every time, not a sample or a skim), consistency and timeliness, and produces evidence as a by-product. It loses human judgment about whether access makes sense for a person's job and the accountability of a manager signing a statement. It adds new risks in the automation itself. I would recommend a hybrid: automate detection and evidence, keep a human decision on ambiguous and privileged cases, and prove the automation works with design and operating tests.

Gains and losses in control terms.

New risks from automation.

• Wrong rules: a logic error silently approves what it should flag.
• Bad or incomplete data: if the HR feed omits contractors, the check never sees them.
• Silent failure: the job stops and nobody notices, so a missing alert looks like clean results.
• Change to the check itself: whoever edits the rules or schedule can weaken the control, so it needs change management and separation of duties (the person who edits rules should not be the one who approves exceptions).
• Alert fatigue if the rules are noisy.

Convincing an assessor. I show design effectiveness (the rules match the stated objective) and operating effectiveness (it ran as designed across the period). Tiny example: design asks whether the rule "flag any account unused for 90 days" fits the requirement; operating asks whether the job really ran each scheduled day and flagged the dormant accounts that existed.

1. Walk through the rules and the data sources against the requirement. Reconcile source counts, for example accounts in the directory versus accounts the check evaluated.
2. Plant known violations in test accounts, say 12 across four rule types (terminated user still active, dormant over 90 days, privileged without ticket, shared account), three per type, and show all 12 are flagged. This proves those rule types work, not that no other cases exist. If all 12 are flagged, that is evidence the rules detect those four types. If, say, 9 of 12 are flagged and all three misses are one type, that rule has a design defect, so I fix it and repeat the plant test before relying on the check.
3. Re-perform a sample of the check's own outputs by hand and trace flagged items to remediation tickets with dates.
4. Show monitoring for job failure and evidence of the job running on schedule across the period.
5. Show the general controls over the automation operated: the controls around the system rather than inside it, such as change management, who can edit the rules or schedule, and logging. An automated control runs the same logic every time, so unlike a person it does not vary from day to day, and a single successful test of it can stand for the whole period as long as nobody could have changed it unnoticed. The general controls are the proof that nobody did. Assessors typically accept testing an automated control once only when these hold, so I test them.

Pitfall. Declaring the automation equivalent because it produces more output. Output volume is not effectiveness.