Cedar Health: Continuous Evidence Under Regulatory Scrutiny
Cedar Health operates patient-facing scheduling services. Fourteen delivery teams deploy on demand, a median of 30 deployments a week. An external auditor sampled 40 production changes and found three with no retrievable evidence of approval or test results, and one developer held standing production access and had approved and deployed their own change. Risk assessments live in a spreadsheet refreshed annually and are not linked to any team backlog. The regulator has asked for evidence that controls operate continuously, not once a year. Security proposes a five-day pre-deployment approval gate for all changes touching patient data, roughly 60% of deploys. In the quarter there were two failed changes, each causing a 40-minute outage; a third was reverted in four minutes by disabling a feature flag. The CTO wants to protect deployment frequency and argues the audit findings are paperwork problems.
1. Separate the control failures from the evidence failures in this scenario and say what each demands. Begin by testing whether the CTO's paperwork framing is defensible.
Read the worked answer
The CTO is partly right and dangerously wrong. Some findings are record-keeping; one is a real control design failure. Conflating them produces the wrong remedy, and so does dismissing all three.
Control failure: segregation of duties. A developer with standing production access approved and deployed their own change. No amount of better documentation fixes this. It demands immediate remediation: remove standing production access, move to time-bound elevation with approval and logging, and make peer review a genuine control (second reviewer cannot be the author, enforced by tooling). Then systemic work: identity and access policy, privileged access review, and deployment rights scoped by environment.
Evidence failure: three of 40 with no retrievable approval or test evidence. Investigate before concluding approvals did not happen. Sample a few of the three: if pipeline logs show tests ran but retention or linking failed, the fix is evidence as a byproduct of the pipeline (immutable, retained, referenced from the change record), not more gates. A 7.5% sampling gap is enough to fail an audit even if the control operated.
Process failure: annual spreadsheet risk assessment unlinked to delivery. Risk management is not operating as a live control. It needs owners, review cadence, and traceability into team backlogs.
The remedy hierarchy matters: the SoD issue is an access and review problem, the evidence issue is a pipeline and retention problem, the risk issue is a governance operating model problem.
2. Evaluate security's five-day pre-deployment approval gate. What would you offer instead, and what must be true for an auditor and regulator to accept it?
Read the worked answer
Reject the gate as designed, on evidence. Sixty percent of 30 weekly deployments is about 18 changes through a five-day human gate. That queue becomes the constraint, work batches up while waiting, and reviewers facing that volume will rubber-stamp within weeks. Worse, batching increases the size and risk of each change, which is the opposite of the stated intent, and the gate does not address either finding: it neither enforces segregation of duties nor guarantees retrievable evidence.
Offer instead: automated, risk-tiered controls with evidence as exhaust.
- Pipeline gates that block rather than ask: automated tests, dependency and secret scanning, static analysis, and a linked change record. A human approving what a machine already verifies adds delay and no assurance.
- Peer review enforced technically, author excluded, for all changes; two-person rule for privileged paths.
- A narrow high-risk class (authentication changes, schema migrations on patient data) reviewed asynchronously by a named reviewer with a published turnaround of hours, not days.
- Progressive delivery with feature flags and automated rollback; the four-minute flag revert is the model to extend, not an anecdote.
What must be true for acceptance. Control objectives mapped explicitly to automated evidence. Immutable logs with a retention policy the auditor can sample directly via read access or export. A documented exception path with approval. Segregation of duties enforced by identity and access management, not by promise. And a pilot: one team, six weeks, sampled evidence shown to the auditor before the model is extended. That converts a design argument into demonstrated operation, which is what the regulator asked for.
3. How would you connect risk assessment to the teams' backlogs without turning it into a field-filling exercise, and how would you measure that it is working?
Read the worked answer
Make risk a work item, not a form. The annual spreadsheet fails because it is a document with no owner and no delivery mechanism. Rebuild it as a live register where each material risk has a named owner, a rating, and either an active backlog item or a documented acceptance decision. Risks that cannot be reduced become explicit accepted risks with a review date, signed by someone accountable.
Connect at the point of work. Threat modelling or a short risk conversation during refinement for changes touching patient data, authentication or data flows, so the analysis happens before design, not before deployment. Encode the common cases as controls tagged to backlog items: a change touching patient identifiers automatically attaches the required checks and evidence, so compliance is a property of the workflow rather than a separate task. Review the register quarterly alongside service reviews, with a trigger-based review whenever a high-severity incident or failed change occurs.
Measure the control, not the paperwork. Track: percentage of high-rated risks with an owner and an active backlog item; time from risk identification to mitigation started; percentage of production changes with complete automated evidence retrieved by sampling; segregation-of-duties exceptions found; and repeat audit findings. A rising count of completed risk forms is not evidence of anything and should be explicitly rejected as a success measure.
Pitfall to name. The fastest way to fail is to add a compliance checkbox to every ticket. Within a month it is filled in by default, the auditor sees uniformity, and real risk is invisible. Keep the imposed fields few, make the rest evidence generated by the pipeline, and audit exceptions rather than attestations.