SOC 2 CC4: monitoring your own controls
CC4 is two criteria asking a question nobody likes: who checks that your controls are working, and what happened when one was not.
CC4 has two criteria. CC4.1 requires that you select, develop and perform ongoing or separate evaluations to establish whether your controls are present and functioning. CC4.2 requires that you evaluate and communicate control deficiencies to the people responsible for fixing them, in a timely manner. In practice, a first audit satisfies CC4 with two artifacts: a dated internal review of your own controls, and a log of the deficiencies it found with dates they were closed.
It is the family where honesty pays. A CC4 record that found nothing is worse evidence than one that found four things and fixed three, because the first reads as a review nobody did.
Ongoing or separate evaluations, which do we need?
- Ongoing evaluations
- Checks built into how you already work. Automated alerting on a control failing, a dashboard someone looks at weekly, a pipeline that blocks a merge without review. Cheap to run, and they produce evidence continuously.
- Separate evaluations
- A deliberate look at whether the control set is working, done apart from daily operations. An internal control review, a mock audit, a readiness assessment, or a penetration test with a remediation plan.
The criterion says ongoing or separate, so either satisfies it in principle. In practice most auditors want to see at least one separate evaluation inside the observation window, because ongoing evaluations tell you a control ran and not whether it was the right control. A single half-day internal review with written notes clears the bar. If you would rather buy it, that is what a readiness assessment produces, and the readiness scorecard is a free version you can run yourself and keep the output of.
What does a deficiency log have to contain?
| Field | Why it is there | What fails without it |
|---|---|---|
| Date identified | Proves the deficiency was found inside the window | An undated entry cannot be tied to the period under test |
| How it was found | Evidences CC4.1, the evaluation itself | Findings with no source read as invented at audit time |
| Control affected | Ties the finding to your control matrix | The auditor cannot assess severity |
| Severity or impact | Shows you triaged rather than logged | Everything looks equally urgent, so nothing was prioritized |
| Owner, a named person | Evidences CC4.2 communication to the responsible party | "Engineering" is not somebody who can be asked what happened |
| Date communicated | CC4.2 says timely, so the gap between found and told is the test | A finding closed three months later with no communication date |
| Date closed and how | Completes the loop | Open items with no plan become report exceptions |
Who can do the review if we have no internal audit function?
Nobody at a 30 person company has an internal audit function, and the criterion does not ask for one. What it asks is that the evaluation is performed by someone able to be objective about the control. Three arrangements that hold up, in ascending order of cost:
- Peer review inside the company. The person who runs access control reviews change management, and the reverse. Cheap, and defensible while the company is small.
- The oversight body you named under CC1.2 performs a documented review of the control set once in the window.
- An external readiness assessment or a mock audit, which also gives you a rehearsal of the request list before the real one arrives.
Whichever you pick, the output is the same: notes with a date, a list of what was examined, and findings. Self-review by the person who owns the control is the one arrangement auditors push back on. Avoid it even where the alternative is awkward.
A penetration test is a CC4 artifact as well as a CC7 one
Most companies file their penetration test against vulnerability management and stop there. The test is also a separate evaluation under CC4.1, and the remediation tracking behind it is CC4.2 evidence. Cite it against both and you have bought one thing that answers two criteria.
How often do we have to do this?
Once inside the observation window is the floor, and for a three or six month first window that is also the sensible answer. Do not write quarterly into the policy for a program in its first year. If your window is twelve months, two reviews spaced across it is a better story than one done in month eleven, because CC4.2 tests timeliness and a review at the end leaves no time to have communicated or closed anything.
Schedule the review for roughly two thirds of the way through the window. Early enough that findings can be closed before fieldwork, late enough that the controls have a run of operation to look at. The timeline page has where this sits relative to everything else.
Get monitoring evidence that covers the window
CC4 asks you to prove you watched your own controls all period, not once. Send your scope and compare firms that set this up early.
Get matchedCommon questions
Does SOC 2 require an internal audit?
No. CC4.1 requires evaluations of whether controls are present and functioning, which can be ongoing monitoring, a peer review, an oversight body review, or an external assessment. A formal internal audit function is an ISO 27001 expectation, not a SOC 2 one.
Will logging deficiencies hurt us in the report?
No, and an empty log usually hurts more. Auditors expect a working program to find things. What creates an exception is a deficiency that was found, never communicated, and never closed, or a log that starts the week before fieldwork.
How many criteria are in CC4?
Two. CC4.1 covers performing evaluations and CC4.2 covers evaluating and communicating deficiencies. It is the second smallest family after CC8.
Can the same person run the control and review it?
It is the weakest arrangement and auditors say so. Where the team is too small to avoid it, document it as a compensating control, have a second person sign off on the review, and say plainly in the system description that objectivity is limited by headcount.