COSO Principle 11: The entity selects and develops general control activities over technology

COSO Principle 11 requires you to define, implement, and keep evidence of technology general controls (ITGCs) that reliably support your SOC 2 control environment, including access control, change management, and technology operations. To operationalize it fast, you need a scoped control inventory, clear ownership, tested workflows, and audit-ready evidence mapped to the systems that process customer data ¹.

Key takeaways:

• Scope the “technology” in-scope first, then build ITGCs for access, change, and operations across that scope ¹.
• Write controls in testable language (who/what/when/tools), and retain artifacts that prove both design and operation ¹.
• Auditors fail teams on Principle 11 more for missing evidence and inconsistent execution than for missing policy language ¹.

You can treat the coso principle 11: the entity selects and develops general control activities over technology requirement as the backbone of your SOC 2 technology controls. Your business apps, cloud infrastructure, identity provider, CI/CD pipeline, ticketing system, and monitoring stack all affect whether your security controls work the way management says they do. Principle 11 is where you prove you have general technology controls that prevent unauthorized change, restrict access appropriately, and keep systems operating reliably.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to stop thinking in “policies” and start thinking in repeatable operational control activities: specific workflows that produce consistent outcomes and evidence. You will need to (1) define the in-scope technology stack, (2) implement a minimum set of ITGCs across it, (3) ensure the controls are owned and executed by engineering/IT, and (4) retain artifacts that allow an auditor to re-perform or inspect the control operation ¹.

This page gives you requirement-level implementation guidance you can put into your SOC 2 program immediately.

Regulatory text

Excerpt (Trust Services Criteria): “COSO Principle 11: The entity selects and develops general control activities over technology” ¹.

Operator interpretation: You must choose and implement IT general controls that are appropriate for your systems and risks, then show those controls operate as designed. “General control activities over technology” typically means:

• Logical access controls (who can access what, how access is granted/removed, and how privileged access is governed)
• System development and change controls (how code/config changes are authorized, tested, approved, and deployed)
• Technology operations controls (monitoring, backups, job processing, incident handling, and other run-the-business controls)

The standard does not prescribe a single tooling stack. It does expect a coherent set of controls that management can explain, operate, and evidence across the technology that supports the service commitments in your SOC 2 report ¹.

Plain-English interpretation (what the requirement really demands)

You need to prevent your technology environment from becoming the weak link in your controls. Even strong policies fail if:

• engineers can push unreviewed changes into production,
• terminated users retain access,
• privileged roles are not tracked,
• production incidents are not detected or handled consistently,
• evidence is scattered across tools with no audit trail.

Principle 11 is satisfied when your ITGCs are selected (intentionally chosen based on your stack and risks), developed (documented and implemented), and operating (performed consistently with proof) ¹.

Who it applies to (entity and operational context)

This applies to service organizations pursuing SOC 2 and any internal teams or third parties that operate in-scope technology ¹. In practice, it applies to:

• Engineering (application code, CI/CD, infrastructure as code)
• IT / Corporate systems (identity provider, device management, collaboration tools)
• Security (monitoring, vulnerability management inputs, incident response coordination)
• DevOps / SRE (production access, logging, alerting, backups, reliability)
• Third parties operating critical parts of the stack (cloud providers, managed service providers, outsourced IT)

Operational contexts where Principle 11 becomes high friction:

• fast release cycles and frequent configuration changes
• shared admin accounts or weak identity governance
• “shadow IT” SaaS tools outside the inventory
• production support via ad-hoc access grants
• startups transitioning from founder-admin to role-based access

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

Step 1: Define scope (systems, boundaries, and “what is technology”)

Create an in-scope system inventory tied to SOC 2 boundaries:

• customer-facing product and production infrastructure
• identity systems (SSO/IdP), source control, CI/CD
• logging/monitoring stack
• ticketing/ITSM (or equivalent)
• key SaaS that stores or processes customer data

Deliverable: a scoped inventory with owners and whether each system is production, staging, or corporate-only. This becomes your testing population anchor.

Step 2: Select your baseline ITGC domains and minimum controls

For most SOC 2 programs, define controls in three ITGC buckets:

A) Access controls

• Joiner/mover/leaver process (provisioning and deprovisioning)
• Privileged access management (admin roles, MFA expectations, break-glass)
• Periodic access reviews for key systems

B) Change management

• Standard change workflow for code and infrastructure changes
• Separation of duties via peer review/approvals
• Emergency change path with after-the-fact review

C) Technology operations

• Centralized logging and alert triage
• Backup strategy and restore testing expectation
• Incident management workflow alignment (who declares, who documents, who closes)

Write these as controls with: owner, trigger, steps, tools, and evidence. Avoid controls that read like aspirations.

Step 3: Develop control procedures that engineers will follow

Convert each control into a runbook-level procedure:

• Where does the request start (ticket, HR feed, access request tool)?
• Who approves (role-based approvers, not named individuals)?
• What is the SLA or timing expectation (use a defined internal standard you can meet)?
• Where is the audit trail (screenshots are last resort; prefer system logs/exports)?

Practical tip: If your company runs on GitHub/Jira/Okta/AWS, design controls so evidence is native to those tools, not manually compiled.

Step 4: Map controls to systems and define testing approach

Build a simple control-to-system matrix:

• rows = controls (access/change/ops)
• columns = in-scope systems
• mark which controls apply to which systems and why

Then define your internal testing method:

• what sample evidence you will pull
• who pulls it
• where it is stored
• how exceptions are tracked and remediated

This reduces auditor back-and-forth because you can show deliberate selection and coverage ¹.

Step 5: Operate and retain evidence continuously

Most SOC 2 failures here are evidence failures. Set up recurring evidence capture:

• access review packages saved to a controlled repository
• change approvals captured via pull request histories and deployment logs
• incident tickets and post-incident reviews retained
• monitoring alerts with triage notes retained where feasible

If you are using Daydream, configure control records that include the “evidence recipe” (exact query/export path, owner, cadence) so collection does not depend on tribal knowledge.

Step 6: Remediate exceptions with a documented, testable path

Define what happens when:

• an access review finds stale access
• a change bypasses peer review
• a production incident lacks a ticket or timeline

Track exceptions, corrective actions, and closure evidence. Auditors often accept occasional exceptions if governance is real and corrective actions are documented.

Required evidence and artifacts to retain

Keep artifacts that prove both design (what you said you do) and operation (what you actually did):

Design artifacts

• ITGC policy or control narrative for access, change, and operations
• system inventory and boundary definition
• role definitions and privileged access model
• change management standard (including emergency changes)

Operating evidence (examples)

• access provisioning/deprovisioning tickets or IdP audit logs
• privileged role assignment logs and approvals
• access review outputs with reviewer sign-off and remediation notes
• pull request records showing review/approval, linked work item, and deployment record
• change exceptions and post-implementation reviews (for emergency changes)
• backup job status reports and evidence of restore tests (as applicable to your program)
• incident tickets with timelines, severity, and closure criteria
• monitoring/alerting evidence that alerts are triaged and closed

Evidence should be retained in a controlled repository with permissions, versioning, and a clear naming convention aligned to your audit period.

Common exam/audit questions and hangups

Expect auditors to press on these areas ¹:

• Scope clarity: “Which systems are in-scope for SOC 2, and why?”
• Completeness: “Do these ITGCs cover identity, production, and change pathways end-to-end?”
• Consistency: “Is the control performed the same way each time, or does it depend on the person?”
• Population and sampling: “What is the population for access changes and production deployments?”
• Privileged access: “Who has admin access, how is it approved, and how do you review it?”
• Emergency change: “How do you prevent ‘emergency’ from becoming the normal path?”

Hangup that causes delays: teams try to prove change management with screenshots. Auditors usually prefer immutable system records (PR history, deployment logs, ticket timestamps).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Unscoped ITGCs. Controls are written broadly (“all systems”) but you cannot evidence coverage.
   Fix: maintain a system inventory and explicitly map controls to systems.

2. Mistake: Access reviews that miss service accounts and admin roles.
   Fix: define what “privileged” means, include cloud roles, database admin, CI/CD admin, and break-glass accounts.

3. Mistake: Change management applies to code but not configuration.
   Fix: include infrastructure as code, cloud configuration changes, and critical SaaS admin changes in scope.

4. Mistake: One-off evidence creation at audit time.
   Fix: implement recurring evidence capture and store artifacts as you go.

5. Mistake: Third parties run key technology but you have no control story.
   Fix: document reliance on third parties and obtain assurance artifacts (for example, their SOC reports) as part of your third-party risk process.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. For SOC 2, the practical risk is a qualified opinion, control exceptions, or an inability to support customer commitments due to weak change/access/operations controls ¹. Operationally, weak Principle 11 execution correlates with preventable outages, unauthorized access, and undetected misconfigurations.

A practical 30/60/90-day execution plan

Days 1–30: Scope and design

• Confirm SOC 2 boundaries and produce an in-scope system inventory with owners.
• Draft control narratives for access, change, and operations in testable language.
• Decide where evidence will live and who collects it.
• Identify quick gaps: missing SSO coverage, missing PR reviews, no formal incident tickets.

Days 31–60: Implement and start producing evidence

• Implement joiner/mover/leaver workflow and privileged access approval path.
• Enforce peer review for production changes and define emergency change procedure.
• Stand up recurring access reviews for key systems.
• Start evidence collection cycles and run an internal “mock sample” pull.

Days 61–90: Stabilize, test, and remediate

• Perform internal control testing against your own evidence.
• Document exceptions and remediation with closure proof.
• Tune evidence quality: replace screenshots with exports/logs where possible.
• Prepare auditor-ready packages: control matrix, system inventory, and evidence index.

If you use Daydream, set up control records with owners, cadences, and evidence checklists so the program runs without calendar-chasing and one-off audit scrambles.

Frequently Asked Questions

What counts as “general control activities over technology” for SOC 2?

Typically access controls, change management, and technology operations controls applied across in-scope systems ¹. Your control set should match your stack and the ways your service could fail due to unauthorized access or change.

Do we need a formal ITIL change management process?

No single methodology is mandated by the criterion ¹. You do need a consistent, evidenced process for authorizing, testing, approving, and deploying changes, including emergency changes.

How do we evidence change management in a CI/CD world?

Use system-of-record artifacts: pull request review history, linked work items, and deployment logs from your pipeline tools. Write the control so the evidence is produced naturally during development and release.

Are access reviews always required?

The criterion expects you to select and develop technology control activities that address risk ¹. Periodic access review is a common way to detect access drift, especially for privileged roles and critical systems.

What about third parties like cloud providers and managed service providers?

If a third party operates in-scope technology, your control environment depends on them. Document the dependency, define what you rely on them for, and collect assurance evidence (often their SOC reports) through your third-party risk process.

What’s the fastest way to reduce audit pain for Principle 11?

Tighten scope, write controls that match how teams already work, and implement an evidence index with clear “how to pull proof” steps. Most delays come from unclear populations and missing audit trails, not from missing policy PDFs.

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