COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations

COSO Principle 16 requires you to run evaluations that verify your internal controls are designed well and actually operating, using a mix of ongoing monitoring and periodic independent (separate) reviews. To operationalize it for SOC 2, stand up a documented monitoring plan, define what gets tested and how often, track issues to closure, and retain clean evidence of every review and remediation cycle ¹.

Key takeaways:

• You need both “always-on” monitoring and periodic independent evaluations, tied to your SOC 2 control set ¹.
• Auditors look for a repeatable evaluation program: scope, methods, results, issue management, and proof of follow-up ¹.
• Evidence quality matters as much as execution: dated outputs, reviewer identity, exceptions, and closure records.

COSO Principle 16: the entity selects, develops, and performs ongoing and/or separate evaluations requirement is the monitoring backbone of your SOC 2 program. Controls can be well-written and still fail in practice. This principle is the requirement to prove you are checking, continuously and periodically, that controls work as intended and that failures get detected and corrected fast enough to protect the trust services commitments you make to customers.

For a Compliance Officer, CCO, or GRC lead, “evaluations” should not mean an annual scramble before the SOC 2 audit. You need an operating cadence: signals that detect drift (ongoing evaluations) plus scheduled testing that challenges assumptions (separate evaluations). The output is not just dashboards; it is decisions, documented exceptions, and tracked remediation.

This page gives requirement-level implementation guidance you can apply immediately: who owns what, how to define scope, how to design a monitoring plan that maps to SOC 2 controls, what evidence auditors request, and how to avoid the most common failure mode: having monitoring activities that occur, but cannot be proven, repeated, or tied to specific controls.

Regulatory text

Requirement (SOC 2 / Trust Services Criteria): “COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations” ¹.

What the operator must do:
You must implement a program of monitoring activities that (1) run routinely as part of operations and (2) run periodically as distinct assessments, to confirm internal controls remain present and effective over time ¹. In a SOC 2 context, this means you can’t treat control design as static; you must validate control operation and detect control degradation (for example, access review slippage, logging gaps, or incomplete third-party due diligence).

Plain-English interpretation

• Ongoing evaluations = monitoring built into day-to-day processes. Examples: alerts for failed backups, SIEM rules for privileged access, ticket queue checks for overdue security reviews, or automated configuration checks.
• Separate evaluations = periodic, more independent reviews. Examples: internal audit-style control testing, management self-assessments with documented sampling, or an external readiness assessment.

Auditors typically read this requirement as: “Show me your monitoring plan, show me it ran, show me what it found, and show me you fixed what mattered.”

Who it applies to (entity and operational context)

This applies to service organizations preparing for, maintaining, or renewing a SOC 2 report under the AICPA Trust Services Criteria ¹. Practically, it applies to:

• The control owners running operational controls (IT, Security, Engineering, HR, Finance, Support).
• The compliance function coordinating testing, evidence, and issue management.
• Management responsible for risk decisions and remediation prioritization.

It matters most when:

• You have fast change (cloud infrastructure, frequent releases, staff turnover).
• You rely on third parties for key systems (hosting, support tooling, payment processors).
• You scale headcount and access grows faster than governance.

What you actually need to do (step-by-step)

Step 1: Define evaluation scope against your SOC 2 control inventory

Create a simple mapping table:

SOC 2 control	Evaluation type	Method	Owner	Output evidence
Access reviews	Ongoing + Separate	Ongoing: alert on dormant admins; Separate: quarterly sample test	IT/Sec + GRC	Alerts + review worksheet

Rules:

• Every in-scope control needs at least one evaluation mechanism.
• Higher-risk controls should have both ongoing monitoring and separate testing.

Step 2: Select monitoring methods that match the control failure mode

Pick methods based on how the control fails:

• Controls that fail silently (logging, backups, monitoring rules): prioritize automated ongoing evaluations (alerts, job failures, drift detection).
• Controls that fail by omission (access reviews, third-party reviews, policy attestations): prioritize workflow-based monitoring (ticket SLAs, due date dashboards) plus separate sampling.
• Controls that fail due to judgment (risk acceptances, incident severity): prioritize separate evaluations (peer review, management review, internal audit-style testing).

Step 3: Write an “Evaluation Plan” that an auditor can execute from scratch

Your plan should be one document with:

• In-scope system boundaries and control list
• Ongoing evaluation activities (signals, thresholds, owners, escalation)
• Separate evaluation schedule (what gets tested, sampling approach, who reviews)
• Criteria for what counts as an exception
• Issue severity definitions and remediation timelines (your policy, not a made-up benchmark)
• Evidence retention locations (systems of record)

If you use Daydream, treat this as a managed object: control → evaluation activities → test steps → evidence checklist → issue workflow. The tool matters less than the discipline, but Daydream helps enforce repeatability and prevents “evidence lives in someone’s inbox.”

Step 4: Perform ongoing evaluations as part of operations (and prove they happened)

Common patterns auditors accept:

• A monitoring dashboard with dated exports and owner review sign-off.
• Alerting rules + incident/ticket records showing triage and closure.
• Scheduled jobs with immutable logs.

Minimum evidence expectation:

• A record that the monitoring ran during the period.
• A record that someone accountable reviewed outcomes.
• A record of what happened when something broke.

Step 5: Perform separate evaluations with independence and documentation

“Separate” does not require a full internal audit department, but it must be meaningfully independent from the daily operator. Options:

• GRC tests controls owned by Engineering/IT.
• Security tests controls owned by IT Ops.
• A cross-functional peer review where the reviewer is not the control performer.

Document separate evaluations like a test:

• Test objective tied to the control
• Period covered
• Population definition (what you could have sampled)
• Sampling rationale and sample items
• Test steps and results per item
• Exceptions and their impact
• Reviewer, date, and approvals

Step 6: Track issues to closure with a real corrective action process

Principle 16 fails most often at the “so what” step. Your issue workflow should include:

• Exception record (unique ID, control mapping, description)
• Severity and decision (fix, mitigate, accept)
• Owner and due date
• Remediation evidence
• Verification step (re-test or validation)
• Closure approval

Step 7: Feed results into control improvements

Your evaluations should change something:

• Update control language if reality differs.
• Add automation if manual steps keep slipping.
• Adjust monitoring thresholds if noise hides real failures.
• Train owners when exceptions repeat.

Auditors will notice recurring exceptions with no design change.

Required evidence and artifacts to retain

Keep evidence in a system with reliable timestamps and access control. Typical artifacts:

• Approved Evaluation Plan mapped to SOC 2 controls
• Monitoring configurations (screenshots/exports of alert rules, job schedules, SIEM rule definitions)
• Ongoing review sign-offs (ticket comments, approvals, meeting minutes with decisions)
• Separate evaluation test workpapers (worksheets, sampled items, results)
• Issue register (exceptions log) with full lifecycle history
• Remediation proof (PRs, change tickets, configuration diffs, policy updates)
• Re-test results and closure approvals

Practical rule: if you cannot show “who reviewed, what they saw, what they decided, and what changed,” assume it won’t pass scrutiny.

Common exam/audit questions and hangups

Auditors tend to probe:

• “Show me the monitoring.” What runs continuously, and how do you know it ran?
• “How do you know the monitor works?” Evidence of tuning, test alerts, or periodic validation.
• “What is separate vs ongoing here?” Teams often label everything “continuous” but cannot show independent testing.
• “Where are exceptions tracked?” Spreadsheets are acceptable only if controlled, versioned, and complete.
• “Did you re-test?” Closure without verification is a recurring hangup.

Frequent implementation mistakes and how to avoid them

1. Mistake: Monitoring exists, but no owner reviews it.
   Fix: assign an explicit reviewer and require a lightweight sign-off trail (ticket comment, approval, or dated export).

2. Mistake: Separate evaluations are informal conversations.
   Fix: convert them into test workpapers with sample-based results and exceptions.

3. Mistake: Exceptions get “fixed” but not linked back to the control.
   Fix: require each issue to reference the impacted control and keep remediation evidence attached.

4. Mistake: Over-monitoring creates noise and trains teams to ignore alerts.
   Fix: track alert quality, tune thresholds, and document rationale for changes.

5. Mistake: No evidence retention standard.
   Fix: define where evidence lives and how long you keep it, then enforce it with a checklist per evaluation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, failure here increases the chance your SOC 2 report contains exceptions, qualifications, or a report delay because auditors cannot confirm controls operated consistently ¹. Operationally, weak evaluations also increase the odds that control failures persist unnoticed (for example, missed access reviews or logging gaps), which can expand incident scope and customer impact.

Practical 30/60/90-day execution plan

Days 1–30: Stand up the program skeleton

• Confirm SOC 2 scope and finalize the control inventory in scope ¹.
• Draft the Evaluation Plan: ongoing signals + separate test schedule + exception criteria.
• Assign owners for each evaluation activity and set evidence locations.
• Build an issue register format and closure workflow (ticketing system or GRC tool).
• Run one pilot separate evaluation on a high-risk control and capture workpapers end-to-end.

Days 31–60: Run evaluations on cadence and harden evidence

• Turn on or formalize ongoing monitoring reviews (weekly or monthly reviews based on risk appetite).
• Execute separate evaluations for a defined tranche of controls and log all exceptions.
• Tune monitoring based on false positives and missed detections; document changes.
• Add a re-test step for remediations and require closure approval by a reviewer.

Days 61–90: Expand coverage and prove repeatability

• Cover remaining in-scope controls with at least one evaluation mechanism.
• Perform a second cycle of ongoing reviews to show continuity across time.
• Trend exceptions: repeat findings, systemic causes, and control redesign needs.
• Prep an “auditor pack” folder: plan, workpapers, issue register, and remediation evidence.

If you are behind, Daydream can help by standardizing test steps, storing evidence with the control record, and running issue workflows with clear ownership and audit trails.

Frequently Asked Questions

Do we need both ongoing and separate evaluations for every SOC 2 control?

The requirement allows “ongoing and/or separate,” but auditors expect enough coverage to detect failure over time ¹. Use both for higher-risk controls and at least one credible evaluation method for all in-scope controls.

What counts as a “separate evaluation” if we don’t have internal audit?

A separate evaluation is a periodic assessment that is meaningfully independent from the daily performer. GRC-led testing, security peer reviews, or management review with documented sampling can qualify if you retain workpapers and exception handling ¹.

How do we show evidence for “ongoing” monitoring without exporting dashboards constantly?

Keep a lightweight review record: a recurring ticket with reviewer sign-off, attached screenshots/exports for key dates, and links to underlying system logs. The evidence must show the monitor ran and someone accountable reviewed outcomes.

Can automated controls replace separate evaluations?

Automation strengthens ongoing evaluations, but separate evaluations still matter for verifying design, confirming automation coverage, and testing edge cases. Auditors often want to see periodic validation that automation is configured correctly and remained in place.

What’s the minimum viable issue register for this principle?

You need a list of exceptions with control mapping, severity, owner, remediation actions, and closure evidence. If you track issues in a ticketing system, ensure tickets can be reported, linked to controls, and show the full lifecycle history.

How should third-party controls be evaluated under Principle 16?

Treat third-party dependencies as part of your control environment: monitor key third-party signals (availability notices, SOC report receipt, SLA breaches) and run periodic reviews of third-party risk decisions. Retain evidence of reviews and follow-up actions.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017