Security Management Controls

The “Security Management Controls” requirement means you must design and operate access controls that reliably restrict technology access rights to authorized users, and you must be able to prove those controls work in practice. Build a governed security management process that covers identity lifecycle (joiner/mover/leaver), authentication, authorization, logging, and periodic access reviews tied to systems and data risk. (COSO IC-IF (2013))

Key takeaways:

• Access restriction is a control activity you must design, implement, and test, not just a policy statement. (COSO IC-IF (2013))
• Focus on the end-to-end identity lifecycle: provisioning, changes, terminations, and privileged access. (COSO IC-IF (2013))
• Your audit outcome depends on evidence: tickets, approvals, logs, access review results, and remediation records. (COSO IC-IF (2013))

Security management controls are the control activities that make “only authorized users have access” true for real systems, real data, and real administrators. Under COSO Principle 11 (Point of Focus), management is expected to select and develop control activities over the security management process so technology access rights are restricted to authorized users. (COSO IC-IF (2013))

For a Compliance Officer, CCO, or GRC lead, operationalizing this requirement comes down to two questions: (1) do we have a consistent process to grant, modify, and remove access based on approved authorization, and (2) can we demonstrate that the process runs effectively over time? The fastest path is to define a clear access-control standard (what “authorized” means), map it to systems in scope, implement a small set of repeatable controls (provisioning approvals, MFA where appropriate, privileged access governance, logging, and periodic access reviews), then collect evidence in a way auditors can follow without guesswork.

This page gives requirement-level guidance you can put into a control library, implement with IT and Security, and defend in an audit using concrete artifacts. (COSO IC-IF (2013))

Regulatory text

Excerpt (verbatim): “Management selects and develops control activities over the security management process to support the restriction of technology access rights to authorized users.” (COSO IC-IF (2013))

What the operator must do: establish and run control activities (not just policies) that prevent unauthorized access and limit authorized access to what is needed. In practice, this means you define how users become “authorized,” how access is granted and changed, how access is removed, how privileged access is controlled, and how you detect and correct breakdowns. You also maintain evidence that these controls operated as designed. (COSO IC-IF (2013))

Plain-English interpretation (what this requirement is really asking)

“Security management controls” is the access-control part of internal control. Your organization must:

• Decide who is allowed to access which systems and data (authorization rules).
• Enforce that decision technically (authentication + authorization).
• Prove it stays enforced over time (monitoring, reviews, logging, remediation). (COSO IC-IF (2013))

Auditors typically fail teams here for one of two reasons: the access process is informal (tribal knowledge, inbox approvals), or evidence is missing (no record of who approved what, no access review results, no proof terminations were timely). The requirement is satisfied when access is consistently restricted and demonstrably governed. (COSO IC-IF (2013))

Who it applies to (entity and operational context)

Entities: the requirement applies broadly to organizations implementing internal control under the COSO Internal Control–Integrated Framework; it is also relevant for internal audit functions assessing those controls. (COSO IC-IF (2013))

Operational scope (where it shows up):

• Systems that support financial reporting, operational reporting, compliance reporting, and the underlying infrastructure those systems rely on.
• Corporate identity platforms (SSO/IdP), directories, HR systems that trigger access changes, ticketing/workflow tools, and privileged access tooling.
• Third-party hosted systems where your users access the provider’s environment (SaaS), because authorization and deprovisioning still sit with you even when infrastructure is outsourced. (COSO IC-IF (2013))

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

Use this as a build checklist for a “security management controls” control objective and its supporting procedures.

1) Define “authorized user” and “authorized access” in operational terms

• Define roles responsible for authorization (business owner/system owner/data owner).
• Set minimum requirements for granting access: requestor identity, business justification, approval, and effective date.
• Define least-privilege expectations for normal users and privileged/admin users. (COSO IC-IF (2013))

Operator tip: write the standard so it can be tested. “Manager approval required” is testable; “access should be appropriate” is not.

2) Inventory systems and classify access risk

• Maintain a system inventory for in-scope applications and infrastructure.
• For each system, record: owner, user populations, authentication method, privileged roles, and logging capability.
• Identify “high-impact” systems (those with sensitive data, broad access, or admin capabilities) for tighter controls and more frequent review. (COSO IC-IF (2013))

3) Implement an identity lifecycle process (joiner / mover / leaver)

• Joiner: access granted only through a tracked request with required approvals.
• Mover: access changes triggered by role changes; remove old access that no longer matches the user’s job.
• Leaver: disable accounts and remove access upon termination; ensure downstream apps follow. (COSO IC-IF (2013))

Where teams stumble: HR termination happens, but app access lingers because there’s no connector, no owner, or no reconciliation process.

4) Standardize authentication and access pathways

• Centralize authentication where feasible (single sign-on and consistent account sources).
• Require strong authentication for systems that warrant it; treat privileged access as a separate tier with stronger controls and tighter monitoring.
• Prohibit shared accounts except where formally approved and controlled; require compensating controls where exceptions exist. (COSO IC-IF (2013))

5) Govern privileged access explicitly

• Define what counts as privileged (system admin, database admin, security admin, “superuser” in SaaS).
• Require documented approval for privileged access, time-bounded access where feasible, and separate admin accounts where appropriate.
• Maintain an inventory of privileged groups/roles per system and reconcile membership through review. (COSO IC-IF (2013))

6) Operate periodic access reviews with remediation

• Establish an access review process owned by system owners/data owners, with a defined scope and review criteria.
• Review at least: privileged access, terminated users, and users with high-risk entitlements.
• Track findings, remove inappropriate access, and record closure evidence. (COSO IC-IF (2013))

Practical test: an auditor should be able to pick a user and trace: request → approval → provisioning → access present → later review → still justified (or removed).

7) Log and monitor for access control breakdowns

• Ensure systems log authentication and authorization events at a level that supports investigations.
• Monitor for signals that matter to access restriction: repeated failed logins, anomalous admin actions, creation of new privileged accounts, disabled MFA, and access granted outside process. (COSO IC-IF (2013))

8) Document control design and test operating effectiveness

• Write a control narrative that ties activities to the requirement: “restrict access rights to authorized users.”
• Define how you test: sampling of access requests, review of approvals, evidence of timely deprovisioning, privileged access review outputs, and remediation tracking. (COSO IC-IF (2013))

How Daydream fits (only if it solves a real friction point): if you struggle to assemble consistent evidence across ticketing, identity, and SaaS admin consoles, Daydream can act as the system of record for control evidence, linking requests, approvals, reviews, and exceptions into an audit-ready package.

Required evidence and artifacts to retain

Retain evidence that proves both design and operation of security management controls:

Governance and design artifacts

• Access control policy/standard and supporting procedures (request, approval, provisioning, deprovisioning). (COSO IC-IF (2013))
• Role/entitlement definitions for key systems, including privileged roles. (COSO IC-IF (2013))
• System inventory with owners and authentication model. (COSO IC-IF (2013))

Operational evidence (the audit accelerators)

• Access request tickets/forms with business justification and approvals.
• Provisioning/deprovisioning records (automated logs or admin evidence) tied back to the request.
• Termination reports and account disablement evidence, including downstream applications.
• Access review packets: population reviewed, reviewer attestation, exceptions, remediation, and closure proof.
• Privileged access roster and approval evidence for membership changes.
• Exception register with risk acceptance, compensating controls, and expiry/renewal documentation. (COSO IC-IF (2013))

Common exam/audit questions and hangups

Auditors and internal assessors tend to probe the same weak spots:

1. “How do you know access is authorized?”
   Expect requests, approvals, and ownership clarity per system. (COSO IC-IF (2013))

2. “Show me terminated users and how you removed access.”
   They will test leavers, and they will test downstream apps, not just the directory. (COSO IC-IF (2013))

3. “Who has admin access and why?”
   Privileged access governance is a make-or-break area because misuse has outsized impact. (COSO IC-IF (2013))

4. “Do you review access periodically, and do you actually remove access?”
   Reviews without documented remediation read as a paper exercise. (COSO IC-IF (2013))

5. “How do you detect access granted outside your process?”
   If admins can grant access directly in SaaS consoles, you need detective controls or reconciliations. (COSO IC-IF (2013))

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Policy exists, but provisioning happens in chat/email	No consistent evidence trail; inconsistent approvals	Force access through a workflow tool; reject “informal” requests except documented emergencies. (COSO IC-IF (2013))
Access reviews are done, but populations are incomplete	Missing apps, missing privileged roles, missing service accounts	Drive reviews from an authoritative inventory; reconcile against actual system exports. (COSO IC-IF (2013))
Terminations handled only in the IdP/directory	SaaS and local accounts persist	Maintain downstream deprovisioning steps or automation; do periodic orphan-account sweeps. (COSO IC-IF (2013))
Privileged access treated the same as normal access	Admin actions can bypass controls and logging	Separate privileged roles, require explicit approvals, maintain a privileged roster, and review it. (COSO IC-IF (2013))
Exceptions never expire	Permanent risk acceptance becomes invisible	Put every exception in a register with an owner and renewal/expiry decision points. (COSO IC-IF (2013))

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, failures in security management controls tend to translate into: unauthorized access to sensitive systems/data, inability to explain access decisions, and inability to demonstrate effective internal control to auditors and stakeholders. Those outcomes create reporting risk, incident response risk, and governance risk even when no breach has been confirmed. (COSO IC-IF (2013))

Practical 30/60/90-day execution plan

(These are phases, not duration promises; adjust to your environment and audit dates.)

First 30 days: stabilize scope and accountability

• Name system owners and access approvers for in-scope systems. (COSO IC-IF (2013))
• Publish an access control standard that defines required approvals, privileged access handling, and minimum logging expectations. (COSO IC-IF (2013))
• Build a single inventory of systems, privileged roles, and authentication methods. (COSO IC-IF (2013))
• Stand up an exception register for shared accounts, legacy apps, and admin console grants. (COSO IC-IF (2013))

Next 60 days: make the process repeatable and testable

• Route access requests through a trackable workflow; require approval capture and attach provisioning evidence. (COSO IC-IF (2013))
• Implement leaver controls that cover downstream apps; perform a targeted sweep for orphaned accounts in high-impact systems. (COSO IC-IF (2013))
• Run your first privileged access review and document remediation to closure. (COSO IC-IF (2013))

Next 90 days: prove operating effectiveness

• Run an access review cycle for key systems; keep complete review packets and remediation logs. (COSO IC-IF (2013))
• Perform a control self-test: sample access requests, terminations, and privileged access changes; document results and fixes. (COSO IC-IF (2013))
• Close gaps found in exceptions: implement compensating controls, tighten admin permissions, or retire legacy access paths. (COSO IC-IF (2013))

Frequently Asked Questions

What counts as an “authorized user” under this requirement?

An authorized user is someone whose access has been approved by the appropriate authority (system/data owner) and provisioned through your defined process. You should be able to show the request, approval, and resulting access in the target system. (COSO IC-IF (2013))

Does this apply if our applications are mostly SaaS?

Yes. Even in SaaS, you control who gets access, what roles they receive, and when access is removed. You still need evidence of approvals, provisioning, deprovisioning, and periodic reviews. (COSO IC-IF (2013))

Are access reviews mandatory, or can we rely on automated provisioning?

Automated provisioning reduces risk, but you still need control activities that confirm access remains appropriate over time, especially for privileged roles and role changes. Access reviews are a common way to demonstrate that ongoing restriction is working. (COSO IC-IF (2013))

How should we handle shared or service accounts?

Treat them as exceptions by default: document the business need, assign an owner, restrict where they can authenticate, and add compensating monitoring and review. Keep the exception record and evidence of periodic validation. (COSO IC-IF (2013))

What evidence do auditors ask for most often?

They usually ask for access request/approval records, proof of provisioning and removals, privileged access lists with approvals, and completed access review packages with remediation. If any of those are missing, expect findings even if your intent is sound. (COSO IC-IF (2013))

What’s the fastest way to reduce audit risk before an upcoming review?

Focus on privileged access governance and leaver deprovisioning first, then run a documented access review for the highest-impact systems. Those areas produce clear evidence and address the failure modes auditors test early. (COSO IC-IF (2013))