DSS06: Managed Business Process Controls

To meet the dss06: managed business process controls requirement, you must define, implement, and continuously evidence the control activities embedded in your end-to-end business processes (not just in IT), with clear ownership, consistent execution, and monitoring for exceptions. Operationalize DSS06 by mapping critical processes to specific controls, testing them, and retaining proof of operation.

Key takeaways:

• Treat business process controls as “how the business runs,” with control owners, control steps, and measurable evidence.
• Start with critical processes (order-to-cash, procure-to-pay, payroll, access provisioning) and document control points and exceptions.
• Audit readiness depends on traceable artifacts: process maps, control narratives, test results, issue logs, and remediation records.

DSS06 in COBIT 2019 focuses on making business process controls real, repeatable, and provable. In practice, this requirement fails less because teams lack controls and more because controls exist informally, vary by team, or have no retained evidence that they ran as designed. A CCO or GRC lead operationalizing DSS06 should think in two layers: (1) the business process, end-to-end; (2) the specific control activities inside that process that prevent or detect errors, fraud, policy violations, or operational breakdowns.

This page is written for operators who need to stand up DSS06 quickly: define scope, assign ownership, document control activities, establish monitoring, and build an evidence trail that holds up in audits and assurance reviews. COBIT is a framework, not a law, so “compliance” here typically means meeting internal governance expectations, satisfying customer assurance needs, or aligning to a broader control program. Your goal is to make business process controls observable, testable, and continuously improved, aligned to COBIT guidance ¹ and common objective mappings used by practitioners ².

What DSS06 requires (plain-English interpretation)

DSS06: Managed Business Process Controls expects you to manage the controls embedded in business processes so they are clearly defined, consistently executed, monitored, and evidenced. The intent is governance over “how work gets done,” including manual controls (approvals, reconciliations) and automated controls (system validations, workflow gates), and the interfaces between business operations and IT.

What auditors and assurance partners look for under DSS06 is straightforward:

• You can identify critical business processes and their risks.
• You can point to specific controls within those processes.
• You can show who owns each control and how it is performed.
• You can show the control operated (evidence) and how exceptions are handled.

Framework references that commonly anchor DSS06 implementation include COBIT’s official program materials ¹ and third-party mappings that help teams align objectives across frameworks ².

Regulatory text

Excerpt (provided): “COBIT 2019 objective DSS06 implementation expectation.” ³

What the operator must do: Treat this as an implementation expectation to (1) define business process control activities, (2) assign accountability, (3) standardize performance, and (4) maintain evidence and monitoring. Your “done” state is a process-control inventory that links each critical process to control points, testing/monitoring, and a corrective action loop.

Who it applies to (entity and operational context)

Applies to: Enterprise IT organizations and the business functions they support, especially where business outcomes depend on repeatable processes and system-enabled workflows ¹.

Operational contexts where DSS06 becomes urgent:

• Financial operations: billing, revenue recognition inputs, refunds, expense approvals, procurement.
• Access and identity lifecycle processes: joiner/mover/leaver, privileged access approvals.
• Customer operations: onboarding, pricing changes, contract approvals, support escalations.
• Data operations: master data changes, data exports, report generation used for decisions.
• Third-party-enabled processes: outsourced payroll, payment processors, fulfillment partners.

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

Step 1: Set scope using “process criticality” rules

1. List your business processes (start with a manageable set).
2. Classify each by impact if it fails (financial loss, customer harm, compliance breach, service outage).
3. Select the highest-impact processes for first-pass DSS06 implementation.

Practical scoping tip: If you already have SOC 2, SOX-like controls, or ISO-aligned process documentation, reuse the same processes first and map them to DSS06 rather than inventing a new universe.

Step 2: Build a process-to-control inventory (your DSS06 backbone)

Create an inventory with these minimum fields:

• Process name and owner (business owner, not only IT)
• Process boundaries (start/end triggers)
• Key risks (what can go wrong)
• Control activity (prevent/detect; manual/automated; frequency)
• Control owner (performer) and control approver (accountability)
• Evidence produced (artifact, system log, report)
• Monitoring/testing approach (who checks, what indicates failure)
• Systems and third parties involved

This inventory is what you will map to DSS06 in your control library.

Step 3: Document control narratives for each key control

For each control, write a short narrative that answers:

• Purpose: what risk it addresses
• Procedure: exact steps a performer follows
• Inputs/outputs: what data is used, what record is produced
• Criteria for approval/exception: pass/fail conditions
• Segregation of duties: who cannot do both steps
• Evidence: where it is stored and how long you keep it
• Fallback: what happens if the system is down or automation fails

Keep narratives short enough to be used, detailed enough to be tested.

Step 4: Standardize the control’s operation (make it repeatable)

Controls drift when “everyone does it their own way.” Standardize with:

• Templates (approval checklists, reconciliation worksheets)
• Workflow rules (ticketing required, required fields, automated validations)
• System permissions aligned to roles
• Defined escalation paths for exceptions

Where possible, prefer automated workflow evidence (system logs, immutable approvals) over screenshots and email threads.

Step 5: Implement monitoring and exception management

For DSS06, monitoring is the difference between a control that exists and a control that is managed.

• Define what constitutes an exception (late approval, missing review, override used, reconciliation mismatch).
• Set an exception intake path (ticket queue or GRC issue register).
• Require disposition codes (accepted risk, remediated, false positive) and closure evidence.
• Track recurring exceptions as a root-cause problem, not a series of one-offs.

Step 6: Test controls and keep results

You need proof the controls operate as designed.

• Define a lightweight test plan per control: what you sample, what you inspect, what “pass” means.
• Perform tests on a cadence aligned to the process risk.
• Record failures, corrective actions, and retest evidence.

If you have Internal Audit or a second line testing function, align test steps to their expectations early to avoid rework.

Step 7: Create a change management link (controls must survive change)

Business processes change through system releases, workflow changes, re-orgs, and third-party transitions. Add DSS06 hooks into:

• Process change approvals (process owner sign-off)
• System change management (control impact assessment)
• Third-party onboarding/offboarding (control responsibilities and evidence access)

Required evidence and artifacts to retain

Use this as an exam-ready checklist:

Artifact	What it proves	Owner
Process inventory with criticality and boundaries	You know what processes matter	GRC + Process owners
Process maps / swimlanes	End-to-end visibility and handoffs	Process owner
Control narratives / procedures	Controls are defined and repeatable	Control owner
RACI for controls	Clear accountability	GRC
Evidence samples (approvals, logs, reports)	Controls operated	Control owner
Exception log + tickets	Monitoring exists and issues are handled	Ops + GRC
Testing plans and results	Controls were tested	2nd line / IA / GRC
Remediation plans + retest proof	Failures are corrected	Control owner
Training/communications for performers	People know the steps	Process owner

Retention approach: keep evidence in a system that preserves integrity and version history (ticketing system, GRC tool, controlled repository). Define naming conventions so you can retrieve evidence quickly by process and period.

Common exam/audit questions and hangups

Expect variants of these:

• “Show me your critical business processes and the controls inside them.”
• “Who owns this control, and what training do they have?”
• “Where is the evidence, and how do you know it wasn’t altered?”
• “How do you detect and resolve exceptions?”
• “How do process controls change when systems or third parties change?”
• “Prove the control runs consistently across teams/regions.”

Hangups that trigger findings:

• Controls exist but are undocumented.
• Evidence exists but cannot be tied to a defined control.
• Process owners think IT “owns” all controls.
• Manual controls have inconsistent performance and no exception trail.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: documenting only IT controls.
   Fix: start from the business process (quote-to-cash, procure-to-pay) and then map IT dependencies.

2. Mistake: “control owner” is a team, not a person/role.
   Fix: assign an accountable role with a named delegate; use a RACI that survives re-orgs.

3. Mistake: evidence is screenshots and email chains.
   Fix: move approvals into systems that generate durable logs (ticketing/workflows) and restrict who can modify records.

4. Mistake: exceptions are handled informally.
   Fix: require tickets for overrides, late approvals, and reconciliation breaks; track root cause and closure proof.

5. Mistake: process changes break controls quietly.
   Fix: add a “control impact assessment” checkpoint to change management and require process owner sign-off.

Enforcement context and risk implications

COBIT is not a regulator, and no public enforcement cases were provided for this requirement in the source catalog. Practically, DSS06 failures show up as audit findings, SOC report exceptions, customer assurance gaps, and operational losses when approvals, reconciliations, or access steps fail without detection ¹.

A practical 30/60/90-day execution plan

Days 0–30: Stand up the DSS06 foundation

• Select in-scope critical processes and assign process owners.
• Build the process-to-control inventory for the first set of processes.
• Draft control narratives for the highest-risk controls.
• Define evidence locations and naming conventions.
• Create an exception intake workflow (ticket queue + required fields).

Days 31–60: Prove operation and close obvious gaps

• Collect evidence samples for each key control and validate completeness.
• Run a first round of control testing (design and operating checks).
• Train control performers on the documented procedures.
• Start a remediation register for gaps and exceptions, with accountable owners.

Days 61–90: Operationalize monitoring and change resilience

• Implement recurring monitoring reports (late approvals, overrides, mismatches).
• Integrate control impact assessment into change management and third-party lifecycle steps.
• Re-test remediated controls and document closure.
• Prepare an audit-ready “DSS06 packet” per process: map, narratives, evidence, test results, issues.

Where Daydream fits (practitioner use)

If your friction is evidence collection and keeping control narratives, testing results, and exceptions connected, Daydream can serve as the system of record for DSS06 mappings, control ownership, and audit-ready evidence requests. The value is practical: faster retrieval, fewer broken links between process documentation and proof, and a cleaner audit trail during reviews.

Frequently Asked Questions

Do I have to document every business process to satisfy DSS06?

Start with critical processes first, then expand. Auditors usually accept a risk-based scope if you can defend the selection criteria and show active management for what you did scope.

What’s the difference between a business process control and an IT control under DSS06?

A business process control sits inside the workflow that produces a business outcome (approval, reconciliation, segregation of duties). IT controls often support that workflow (access controls, logging, change management), but DSS06 expects the end-to-end view.

How do I handle manual controls without creating mountains of screenshots?

Use structured templates and ticket-based approvals so evidence is generated as part of the workflow. When a manual control must remain manual, define a standard worksheet and a controlled storage location with version history.

Who should own DSS06 controls: IT, Finance, Operations, or Compliance?

The business function that performs the process should own the control operation; GRC owns the framework mapping, oversight, and testing coordination. IT owns enabling controls and system configuration, not the business approval itself.

What evidence is most persuasive in an audit?

System-generated records tied to a defined control (workflow approvals, immutable logs, reconciliation reports with sign-off). Pair each evidence item to a control narrative so reviewers can trace “control defined” to “control executed.”

How do third parties affect DSS06 process controls?

If a third party performs part of the process (payroll, fulfillment, payment processing), define control responsibilities, required evidence, and how you get it on demand. Also document how you monitor the third party’s performance against your process control needs.

Footnotes

1. ISACA COBIT overview

2. OSA COBIT 2019 objective mapping

3. ISACA COBIT overview; Source: OSA COBIT 2019 objective mapping