Technology General Controls

Technology General Controls (TGCs) are the baseline IT controls you must design and operate so your systems process, store, and report information reliably and securely. Under COSO Principle 11, you need controls over technology infrastructure, security management, and system acquisition/development, plus evidence that these controls consistently support your business objectives (COSO IC-IF (2013)).

Key takeaways:

• TGCs are “controls over the environment,” not business-process controls; they determine whether automated controls and system reports can be trusted.
• Scope TGCs to the systems that support financial, operational, and compliance objectives, then map each system to required control domains.
• Audits fail on missing evidence, unclear system boundaries, and weak change/access governance; fix those first.

If you own a control environment, you already rely on technology to achieve objectives: producing accurate reports, keeping data confidential, processing transactions completely, and maintaining service availability. COSO Principle 11 turns that reliance into a requirement: select and develop general control activities over technology that support objective achievement (COSO IC-IF (2013)). Practically, that means building a defensible set of controls that make your tech stack predictable, governed, and recoverable.

For a CCO, GRC lead, or compliance officer, the fastest way to operationalize TGCs is to treat them as a scoped control set tied to specific systems and risks. Start with “what systems matter,” then implement a minimum set of controls that auditors can test: access management, change management, backups and recovery, secure configuration, incident response linkages, and third-party governance where they operate your systems. You also need clean evidence: tickets, approvals, logs, access reviews, change records, and recovery test results.

This page gives requirement-level guidance you can implement quickly: scope rules, step-by-step build, what evidence to retain, common audit questions, and a practical execution plan.

Regulatory text

Excerpt (COSO Principle 11 – Control Activities): “The organization selects and develops general control activities over technology to support the achievement of objectives.” (COSO IC-IF (2013))

What the operator must do

You must identify which technologies support your objectives (financial reporting, operational reliability, compliance), then design and operate a set of IT general controls that keep those technologies secure, stable, and governed (COSO IC-IF (2013)). The control set must cover, at a minimum:

• Technology infrastructure (availability, backup, recovery, configuration)
• Security management (logical access, authentication, privileged access, monitoring)
• Technology acquisition, development, and maintenance (change management, SDLC governance, testing/approvals)

COSO does not prescribe specific control procedures. Your job is to pick controls that fit your environment and can be tested with objective evidence (COSO IC-IF (2013)).

Plain-English interpretation (what “Technology General Controls” really means)

TGCs are the controls that make your systems trustworthy. If you can’t show who had access, what changed, when it changed, and how you would recover from failure, then:

• Reports from the system become suspect.
• Automated controls that run “inside” the system become hard to rely on.
• Data integrity and confidentiality risks increase.
• You end up compensating with manual controls, which are expensive and fragile.

A good TGC program answers four audit-grade questions:

1. Access: Who can do what in the system, and who approved it?
2. Change: What changed in the system, and was it tested and approved before release?
3. Operate: Is the system configured securely and monitored so issues are detected and handled?
4. Recover: If the system fails or data is corrupted, can you restore it within business needs?

Who it applies to (entity + operational context)

Applies to: Organizations implementing or aligning to the COSO Internal Control – Integrated Framework, including internal audit functions assessing control activities (COSO IC-IF (2013)).

Operationally, you should apply TGCs where technology supports objectives, such as:

• Core business applications (ERP, billing, trading, claims, case management)
• Financial reporting systems and data pipelines
• Identity platforms (SSO/IAM), endpoint management, and key infrastructure
• Databases and data warehouses that feed management reporting
• Material third-party systems where a third party operates/hosts your environment (cloud hosting, SaaS platforms, managed service providers)

A practical scoping rule: if the system produces data you use to make decisions, report results, serve customers, or meet compliance commitments, it belongs in TGC scope.

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

Step 1: Define “objectives” and translate them into system scope

1. List your top objectives (financial reporting integrity, customer data confidentiality, operational availability, regulatory commitments).
2. Identify the systems that support each objective.
3. For each system, identify key reports, interfaces, and automated controls the business relies on.

Output: a system inventory tied to objectives (a simple table is enough).

Step 2: Set your TGC control domains and minimum baseline

Create a baseline that covers the three COSO Principle 11 areas (COSO IC-IF (2013)):

A) Security management (logical access)

• Joiner/mover/leaver process tied to HR or authoritative source
• Role-based access (or justified direct entitlements where roles don’t exist)
• Privileged access management (separate admin accounts, approvals, logging)
• Periodic access reviews for sensitive systems (admin roles, finance roles, data admin roles)
• Authentication standards (MFA where feasible; documented exceptions)

B) Technology acquisition, development, and maintenance (change management / SDLC)

• Change request logging (ticketing)
• Impact assessment (what could break, what controls/reports are affected)
• Segregation of duties between developer and approver (or documented compensating review)
• Testing evidence (UAT signoff, test results, rollback plan)
• Approval before production deployment
• Emergency change process with after-the-fact review

C) Technology infrastructure (operations, configuration, backup/recovery)

• Secure configuration baselines for critical components (servers, databases, network, cloud)
• Patch and vulnerability management process with documented risk acceptance
• Backup schedules and restore testing for critical systems
• Job monitoring where batch processing exists (interfaces, ETL, scheduled jobs)
• Logging/monitoring for security and availability events
• Incident response integration: how you detect, triage, and document incidents

Output: a TGC “control standard” that states what must be true for in-scope systems.

Step 3: Map controls to each in-scope system (avoid “one policy covers all”)

For each system, document:

• System owner and technical owner
• Hosting model (on-prem, cloud, SaaS)
• In-scope environments (prod, staging, dev)
• Which TGCs apply, and where evidence lives (tickets, IAM logs, cloud console exports)

Operator tip: SaaS systems still need TGCs. Your controls shift to access governance, configuration management, vendor/third-party oversight, and monitoring of administrative actions.

Step 4: Implement control operation and evidence capture (make audits easy)

Auditors test what happened, not what you intended. For each control:

• Define the control statement (what you do)
• Define frequency (event-driven, periodic, continuous)
• Assign an owner
• Define how evidence is produced and where it is stored
• Define what constitutes an exception and how it is remediated

If you do nothing else, standardize evidence collection. Most “failed controls” are “couldn’t produce evidence” problems.

Step 5: Build monitoring and exception management

• Track exceptions (expired access reviews, unapproved changes, missing backups, overdue patches) in a register.
• Assign remediation owners and due dates.
• Document risk acceptance when remediation is not immediate, including compensating controls.

Step 6: Test operating effectiveness and close gaps

Before an external audit or internal assessment:

• Select samples (access changes, privileged grants, production changes, backup restore tests).
• Verify evidence quality (dated approvals, traceable tickets, consistent logs).
• Fix design gaps (missing approvals, no SoD, unclear emergency changes).

Required evidence and artifacts to retain

Keep evidence aligned to control domains. Typical artifacts include:

Governance and scope

• System inventory tied to objectives
• Data flow diagrams or interface lists for key systems (as available)
• RACI for system ownership, access approval, and change approval
• TGC control standard / control narratives (by system or platform)

Access management

• Access request/approval tickets
• Role/entitlement lists and role definitions
• Privileged access assignment records and admin activity logs
• Access review evidence (reviewer, date, population, results, remediation tickets)
• Termination deprovisioning evidence (HR trigger + account disable logs)

Change management / SDLC

• Change tickets with approvals
• Test evidence (UAT signoff, test cases, results)
• Deployment records (release notes, pipeline logs)
• Emergency change records with post-implementation review

Infrastructure operations

• Backup configuration and backup job results
• Restore test evidence (what restored, outcome, issues, remediation)
• Monitoring/alerting configurations and incident tickets
• Patch/vulnerability scans, remediation tracking, risk acceptances
• Configuration baseline documentation and drift checks (where applicable)

Common exam/audit questions and hangups

Expect auditors and examiners to push on:

1. “Show me your in-scope systems and why they’re in scope.”
   Hangup: inventory exists but isn’t tied to objectives or reporting.

2. “How do you ensure only authorized access?”
   Hangup: approvals exist, but the approver is not the right owner; no evidence of periodic review.

3. “Prove changes are tested and approved before production.”
   Hangup: tickets lack test evidence; approvals happen after deployment.

4. “What about privileged access?”
   Hangup: shared admin accounts, no logging, or admins approving their own access.

5. “Can you recover?”
   Hangup: backups exist, but no restore testing evidence.

6. “How do you control third-party hosted systems?”
   Hangup: reliance on a third party without defined internal controls over configuration, access, and oversight.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating TGCs as “IT’s problem.”
  Fix: Assign control ownership jointly. Business owners approve access; IT operates controls.

• Mistake: Scoping every system.
  Fix: Scope by objectives and materiality. Start with systems that feed reporting and sensitive processing.

• Mistake: Policies without operational mechanics.
  Fix: Convert policy into testable procedures: who, what evidence, where stored.

• Mistake: No clear population for access reviews.
  Fix: Define populations (admins, finance roles, database write access). Save the export used for the review.

• Mistake: Emergency changes become the default.
  Fix: Define “emergency,” require post-implementation review, and track trend lines internally.

Enforcement context and risk implications

COSO is a framework, not an enforcement body. Still, weak TGCs raise real control risk: if your technology environment lacks access governance, controlled change, and recovery discipline, you can’t credibly claim that system outputs support objective achievement as required by Principle 11 (COSO IC-IF (2013)). In practice, that leads to adverse internal audit results, expanded external audit testing, and heavier reliance on manual compensating controls.

Practical 30/60/90-day execution plan

First 30 days: Establish scope + baseline

• Build the system inventory tied to objectives.
• Select in-scope systems (start with the most relied-on platforms).
• Publish a TGC baseline standard across access, change, and infrastructure.
• Identify evidence sources (ticketing, IAM, cloud logs) and gaps.

Days 31–60: Implement control operation and evidence capture

• Stand up/standardize access request and approval workflow for in-scope systems.
• Implement or tighten change management requirements (testing + approvals + emergency change documentation).
• Document backup and recovery ownership; schedule a restore test for critical systems.
• Create an exception register and remediation workflow.

Days 61–90: Test, remediate, and prepare for audit

• Perform a mini operating effectiveness test (sample access grants, changes, terminations, backups).
• Fix repeat failures (missing approvals, incomplete tickets, unclear populations).
• Formalize third-party oversight for hosted systems (who reviews access/config, what evidence retained).
• Produce an audit-ready evidence binder (folders by system and control domain).

Where Daydream fits: If you’re coordinating multiple systems, owners, and third parties, Daydream can centralize control narratives, map controls to systems, and standardize evidence requests so you stop chasing screenshots and spreadsheets across teams.

Frequently Asked Questions

What systems should I include in Technology General Controls scope first?

Start with systems that directly support your objectives, especially financial reporting outputs, sensitive data processing, and operationally critical services (COSO IC-IF (2013)). If a system’s reports drive decisions or compliance commitments, include it early.

Do TGCs apply to SaaS applications where the third party runs the infrastructure?

Yes. Your control emphasis shifts to access governance, configuration control, monitoring of admin activity, and third-party oversight. You still need evidence that your organization controls what it can control in the SaaS tenant.

What’s the minimum evidence an auditor will expect for access management?

A traceable record of access requests, approvals by appropriate owners, provisioning actions, and periodic reviews for sensitive access. Evidence must show who approved, when, and what was granted or removed.

How do I handle segregation of duties in small teams where the same person builds and deploys?

Document compensating controls such as independent review of code changes, post-deployment review, or approval by a manager who is accountable for the system’s outcomes. Make the review evidence easy to retrieve.

What’s the fastest way to improve change management audit outcomes?

Require three things for every production change: a ticket, testing evidence, and an approval timestamp that precedes deployment. Tighten emergency change definitions and require after-the-fact review documentation.

How do I operationalize TGCs across multiple third parties?

Assign an internal owner per third party system, define what configurations and access you control, and standardize evidence requests and review cadence. Central tracking in a GRC workflow prevents coverage gaps when third parties or internal owners change.