Technology Acquisition and Development Controls

“Technology Acquisition and Development Controls” means you must put documented, testable controls around how your organization selects, buys, builds, changes, and maintains technology so systems meet security and operational requirements throughout their lifecycle (COSO IC-IF (2013)). Operationalize it by gating every new system and material change through defined approval, security-by-design review, testing, and controlled release, with evidence retained.

Key takeaways:

• Treat acquisition and development as a controlled lifecycle: intake → risk review → build/buy decisions → testing → release → ongoing maintenance (COSO IC-IF (2013)).
• Your fastest audit win is consistent change control with security reviews, test evidence, and approvals for every material change.
• Tie controls to real assets and owners: systems, data, infrastructure, and third parties that deliver or touch them.

This COSO point of focus sits inside Principle 11 (Control Activities) and is commonly tested indirectly. Auditors rarely ask, “Do you comply with Principle 11?” They ask whether your technology changes are controlled, whether new systems are vetted, whether access and configurations are hardened, and whether outages or incidents trace back to sloppy releases or unmanaged third-party technology.

The requirement is simple but operationally broad: management must select and develop control activities over the acquisition, development, and maintenance of technology and its infrastructure (COSO IC-IF (2013)). That scope includes purchased software (SaaS and on-prem), internally developed applications, infrastructure (cloud accounts, networks, endpoints), and the tooling that runs your control environment (identity, logging, EDR, CI/CD). It also includes technology delivered by third parties, where your control activities must extend through contracting, onboarding, and ongoing change management.

If you need a quick implementation path, anchor on three “gates” you can enforce: (1) a standardized intake and risk classification for any new technology, (2) an SDLC/change management control set with security requirements and testing evidence, and (3) a maintenance cadence that keeps systems supported, patched, and monitored with clear ownership.

Regulatory text

Text (excerpt): “Management selects and develops control activities over the acquisition, development, and maintenance of technology and its infrastructure.” (COSO IC-IF (2013))

What you, the operator, must do: establish documented controls that govern (a) how technology is acquired (buy/build decisions, third-party onboarding), (b) how technology is developed or configured (SDLC, secure configuration, testing), and (c) how technology is maintained (patching, upgrades, end-of-life, operational monitoring). These controls must be designed, implemented, and evidenced in a way that supports your internal control objectives (COSO IC-IF (2013)).

Plain-English interpretation (what this means day to day)

You need a repeatable way to prevent “surprise technology” and “unsafe changes.” Every new system and every meaningful change must:

1. Have an accountable owner and defined purpose.
2. Be risk-ranked based on the data and processes it touches.
3. Meet baseline security and operational requirements before it goes live.
4. Be released through controlled change management with testing and approvals.
5. Stay supported and monitored after launch.

If you cannot show intake records, risk/security reviews, test results, approvals, and post-release operational ownership, auditors will treat the environment as unmanaged, even if the technology works.

Who it applies to (entity + operational context)

Entity types: any organization implementing COSO-aligned internal control, including teams assessed by internal audit (COSO IC-IF (2013)).

Operational scope (practical):

• Business applications: ERP, finance systems, HRIS, CRM, underwriting, claims, billing, payments.
• Infrastructure: cloud subscriptions, networks, endpoints, identity providers, databases.
• Delivery pipelines: CI/CD, source control, artifact repositories, infrastructure-as-code.
• Third parties: SaaS providers, managed service providers, implementation partners, contractors building or administering systems.
• High-impact areas: systems that support financial reporting, regulatory reporting, customer data, production operations, and control monitoring.

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

1) Build an authoritative technology inventory with ownership

• Define what counts as “technology” (apps, SaaS, cloud accounts, key tools, infrastructure components).
• Assign an asset owner (business) and technical owner (IT/security) for each item.
• Tag each asset with: data sensitivity, business criticality, and whether it supports key controls or reporting.

Operator tip: if you can’t name the owner, you can’t enforce maintenance and change controls.

2) Implement a standardized intake and approval workflow for new technology

Create a single intake path for:

• New software purchases and renewals.
• New internally developed applications.
• New infrastructure (new cloud accounts, new network segments).
• Material expansions (new integrations, new data types).

Minimum intake fields:

• Business purpose and requesting sponsor.
• Data categories (customer data, employee data, financial data).
• Integration points and privileged access requirements.
• Third-party involvement (implementation partner, hosting provider).

Approvals to require (right-sized by risk):

• Business owner approval.
• IT architecture/operations approval.
• Security review approval.
• Procurement and legal/contracting approval for third parties.

3) Risk-classify technology to drive control depth (tiering)

Define a simple tier model (for example: low/medium/high impact) based on:

• Data sensitivity and volume.
• External exposure (internet-facing, APIs).
• Privilege level (admin access, production write access).
• Business criticality (downtime impact).
• Regulatory/control relevance (supports reporting or key controls).

Then map tiers to required controls. High-impact systems trigger deeper reviews, stronger testing evidence, and stricter release approvals.

4) Define SDLC / configuration standards and “security-by-design” checkpoints

For custom development or configuration-heavy implementations:

• Set minimum engineering standards: code review, secrets handling, dependency management, logging requirements.
• Require security review for design and major changes (threat modeling or an architecture/security review memo).
• Establish baseline configuration hardening for systems and cloud services (documented build standards).

For buy/implement:

• Require implementation security review (how the SaaS is configured, SSO/MFA, roles, logging, data retention).
• Require third-party onboarding controls (due diligence, contract controls, access boundaries) consistent with the technology’s tier.

5) Enforce change management from request through release

Change control is the control activity auditors most consistently expect to see.

Minimum control steps for production changes:

1. Change request ticket with description, impacted systems, and rollback plan.
2. Risk assessment (impact, security considerations, downtime).
3. Testing evidence appropriate to the change (unit/integration/UAT as applicable).
4. Approval by appropriate role (system owner; security for high-risk changes).
5. Controlled deployment (separation of duties where feasible; scheduled windows for higher-risk systems).
6. Post-implementation verification and incident capture if something breaks.

6) Operational maintenance controls (keep technology supportable)

Define and evidence:

• Patch and update ownership for infrastructure and key applications.
• End-of-life tracking (software versions, unsupported systems).
• Vulnerability intake and remediation workflow (triage, fix, retest).
• Monitoring and logging expectations for critical systems (what is logged, who reviews, and escalation paths).

7) Extend controls to third parties and implementation partners

Where third parties build, host, or administer systems:

• Put change notification and approval expectations into contracts and SOWs.
• Require visibility into release notes and material changes that affect security/availability.
• Control administrative access (named accounts, least privilege, MFA, logging).
• Ensure offboarding: revoke access, return data, confirm destruction where required.

8) Test the control set and close gaps

• Select samples of new systems and changes.
• Verify artifacts exist (tickets, approvals, test evidence).
• Track exceptions with owners and due dates.
• Feed recurring failures into process improvements.

Required evidence and artifacts to retain

A tight evidence set keeps audits predictable. Retain:

• Technology inventory with owners, tiering, and review timestamps.
• Intake records for new technology (request, data classification, approvals).
• Architecture/security review artifacts (design review notes, sign-offs).
• Third-party due diligence and contracting artifacts for technology providers (security review outputs, contract security terms, DPAs if used).
• Change management tickets with:
  • test evidence (screenshots, test cases, CI results),
  • approvals,
  • deployment record,
  • rollback plan,
  • post-change verification.
• SDLC standards and secure configuration baselines.
• Patch/vulnerability tracking records (triage decisions, remediation evidence).
• Exception register (what was waived, by whom, why, compensating controls).

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you approve and risk-rank new SaaS before purchase.”
• “How do you ensure security requirements are included in technology projects?”
• “Provide a sample of production changes with evidence of testing and approval.”
• “Who owns patching and end-of-life decisions for this system?”
• “How do you manage third-party admin access and changes performed by an MSP?”

Common hangups:

• Inconsistent evidence: teams do the work but don’t retain the artifacts in one place.
• Tiering not enforced: everything is “high priority,” so controls get bypassed in practice.
• Shadow IT: business buys SaaS outside intake, then asks IT to “make it compliant.”

Frequent implementation mistakes (and how to avoid them)

• Mistake: policies with no workflow. Fix: implement a single intake form and a required ticket type for changes; make the tooling the enforcement point.
• Mistake: “security review” equals a meeting. Fix: require a written outcome (approve/approve with conditions/reject) stored with the intake or change record.
• Mistake: no ownership after go-live. Fix: require an operational owner as a release gate; no owner, no production launch.
• Mistake: third parties treated as separate. Fix: bring third-party technology under the same gates; contract for notice of material changes and access controls.

Enforcement context and risk implications

No public enforcement sources were provided for this requirement. Practically, weak technology acquisition and development controls show up as control failures, outages, and security incidents that cascade into audit findings and reporting risk. For COSO-based programs, auditors often map this area to general IT controls: change management, access controls, operations, and system development governance (COSO IC-IF (2013)).

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop new risk)

• Publish a minimum control standard: “No new technology or production changes without tickets, approvals, and test evidence.”
• Stand up a technology intake workflow (even if lightweight) and route it to security + IT.
• Start an inventory baseline: list critical systems, owners, and where they run.

Days 31–60 (make it repeatable)

• Implement tiering and map tiers to required reviews and evidence.
• Standardize change templates (risk, testing, rollback, approvals).
• Define secure configuration and SDLC minimums for high-impact systems.
• Add third-party checkpoints to procurement: security review required before signature for high-impact technology.

Days 61–90 (prove it works and prepare for audit)

• Perform a mini internal audit: sample new acquisitions and production changes; verify artifacts end-to-end.
• Close top gaps (missing approvals, missing test evidence, unclear ownership).
• Formalize maintenance governance: patch ownership, end-of-life tracking, and vulnerability remediation workflow.
• Optional: use Daydream to centralize technology intake, third-party due diligence records, and change evidence requests so you can produce a complete audit packet without chasing teams across tools.

Frequently Asked Questions

Do we need a full SDLC program to satisfy this COSO point of focus?

You need controls that match your risk. If you buy mostly SaaS, focus on intake, configuration standards, and change control for integrations and permissions. If you build software, add documented SDLC checkpoints and testing evidence (COSO IC-IF (2013)).

What counts as “technology acquisition” in practice?

Any new system or service that processes your data or supports operations, including SaaS, cloud subscriptions, and managed services. Renewals can count if scope, data, or integrations materially change.

How do we handle emergency production changes without failing audit?

Allow an emergency path, but require documentation: who approved, what testing occurred (even limited), and post-change verification. Track emergencies as exceptions and review them for root cause and prevention.

Our business units buy tools directly. How do we control shadow IT?

Make procurement and SSO the choke points. Require intake approval for contract signature and require identity integration for access, which forces tools into your inventory and control processes.

What evidence is most persuasive to auditors?

End-to-end change records and acquisition records: a ticket that shows risk review, test evidence, approvals, and release confirmation. Auditors trust artifacts that demonstrate a controlled workflow more than narrative explanations.

How does this connect to third-party risk management?

A large portion of “acquired technology” is delivered by third parties. Treat third-party onboarding, contract controls, and ongoing change notifications as part of your technology acquisition control set (COSO IC-IF (2013)).