BAI02: Managed Requirements Definition

BAI02: Managed Requirements Definition requires you to run a controlled, traceable requirements process for business, regulatory, security, and technology needs so that every change or solution can be shown to meet approved requirements. To operationalize it fast, stand up a single requirements intake, define ownership and approval gates, and maintain end-to-end traceability from requirement to design, testing, and release evidence.

Key takeaways:

• Establish one authoritative requirements lifecycle with clear owners, approvals, and change control for requirements.
• Maintain bidirectional traceability from requirement → solution components → test results → release, with audit-ready evidence.
• Treat regulatory and control requirements as first-class requirements, not “nonfunctional notes,” and prove they were tested.

BAI02: managed requirements definition requirement is where many IT, security, and GRC programs quietly fail audits: the work gets done, but nobody can prove that what was built matches what was required, who approved it, and how conflicts were resolved. COBIT frames BAI02 as an objective expectation for defining and managing requirements as a formal practice, not as ad hoc documentation scattered across tickets, emails, and slide decks. ¹

For a Compliance Officer, CCO, or GRC lead, BAI02 is less about picking a specific tooling stack and more about demonstrating control over “what the business asked for,” “what obligations apply,” and “what engineering delivered,” with a clear line of sight through approvals and testing. Your fastest path is to standardize intake, enforce minimum requirement quality, and require traceability evidence in delivery workflows (Agile, DevOps, traditional SDLC). COBIT is a framework (not a law), but many regulated organizations map it to internal control expectations and use it to pass audits and client security reviews. ²

Regulatory text

Framework excerpt (provided): “COBIT 2019 objective BAI02 implementation expectation.” ³

Operator meaning: COBIT expects you to define requirements in a managed way and manage them through the solution lifecycle. Practically, you must be able to show:

• A repeatable method to elicit, document, prioritize, approve, and change requirements.
• Requirements include business needs and constraints, plus security, privacy, resilience, and regulatory/control requirements where applicable.
• Traceability from requirements to delivery artifacts (design/configuration, test results, acceptance, and release).

This is what auditors look for: control ownership, consistent artifacts, and proof the process ran for real work, not just a policy.

Plain-English interpretation

BAI02 means: “No build without a requirement, and no requirement without an owner, approval, and a proof trail to what was delivered.”

If your teams ship software, implement SaaS, change configurations, or roll out infrastructure, you need a mechanism that prevents these failure modes:

• Building the “right thing” but with no evidence it matched approved needs.
• Implementing controls late because security requirements were never captured as requirements.
• Accepting production risk because requirement changes were made informally (chat/email) without approval or testing impact assessment.

Who it applies to (entity and operational context)

Applies to:

• Enterprise IT organizations and technology functions using COBIT as a governance framework. ¹

Operational contexts where BAI02 matters most:

• Application development (Agile or waterfall) and platform engineering.
• SaaS implementations and major configuration changes (ERP/CRM/HRIS).
• Security program delivery (e.g., IAM changes, logging rollouts).
• Third-party integrations where requirements span contractual, security, and technical obligations.
• Regulated or audited environments where you must demonstrate design-to-test-to-release discipline.

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

1) Define ownership and the “system of record” for requirements

• Assign a Requirements Process Owner (often Product, PMO, or IT Governance) and a Control Requirements Owner (often GRC).
• Pick the authoritative repository: a requirements module in your ALM tool, a structured ticket type, or a controlled document set.
• Define scope: what must follow BAI02 (apps, infrastructure-as-code, major SaaS changes, integrations).

Output: Requirements Management Procedure + RACI.

2) Standardize requirement quality (minimum viable requirement standard)

Create a required template (in the tool, not a Word doc people ignore). Minimum fields that drive auditability:

• Unique requirement ID
• Requirement type (business, regulatory/control, security, operational, technical)
• Owner and approver
• Acceptance criteria (testable)
• Priority and rationale
• Dependencies and constraints
• Trace links (design/work items/tests/releases)

Tip: Force testability. If the acceptance criteria cannot be tested, the requirement is not ready.

3) Implement a controlled intake and triage workflow

Build a single intake path and a triage meeting/cadence (Product + Architecture + Security/GRC as needed):

• Log new requirements.
• Validate completeness.
• Identify regulatory/control implications (SOX, privacy, retention, access control) as requirements, not as “comments.”
• Decide disposition: approve, defer, reject, or request clarification.

Control point: No work starts until requirements meet the minimum standard and have an owner.

4) Establish approval gates and change control for requirements

Define when approvals are required and by whom:

• Initial requirement approval (business owner + technical owner).
• Security/control requirement approval (Security/GRC).
• Material changes (scope, risk, control impact) require re-approval.

Make requirement changes visible:

• Versioning or change history.
• A change reason and impact summary.
• Updated traceability and test plan impact.

5) Build traceability from requirement to delivery evidence (end-to-end)

This is the operational heart of BAI02. Implement bidirectional trace links:

• Requirement → epics/stories/tasks
• Requirement → architecture/design decision record (or configuration spec)
• Requirement → test cases (manual or automated) and results
• Requirement → release record/change ticket

If your environment is Agile, treat the “requirement” as an epic/feature with controlled fields and link stories/tests beneath it.

6) Validate requirements during testing and acceptance

Add explicit checks in test and acceptance steps:

• Test plan maps to requirement IDs.
• UAT sign-off references requirement IDs and acceptance criteria.
• Exceptions are documented with risk acceptance and compensating controls (if applicable).

7) Monitor and continuously improve

Operate BAI02 as a control, not a one-time project:

• Periodic sampling of delivered changes to confirm traceability completeness.
• Metrics that reflect control health (e.g., % of releases with complete trace links, count of requirement changes after build starts). Avoid fabricated benchmarks; set your own thresholds.

Required evidence and artifacts to retain

Keep artifacts in the system of record with retention aligned to your audit needs.

Governance artifacts

• Requirements Management Procedure (BAI02 procedure)
• RACI / ownership assignment
• Requirement template/standard (fields + definition of done)
• Approval matrix (who approves what, and when)
• Traceability standard (what must link to what)

Operational evidence ¹

• Requirement records with:
  • Owner, approver, approval timestamps
  • Acceptance criteria
  • Change history/versioning
• Triage/decision logs (meeting notes or workflow states)
• Linked delivery artifacts:
  • Design records / configuration specifications
  • Work items (epics/stories/tasks) mapped to requirements
  • Test cases and results mapped to requirements
  • UAT sign-off mapped to requirements
  • Release/change record referencing requirement IDs
• Exceptions:
  • Documented deviations, risk acceptance, compensating controls, and expiry date for acceptance

Practical evidence tip: Store screenshots only as a last resort. Prefer native exports or immutable system logs.

Common exam/audit questions and hangups

Auditors and client assessors tend to probe these points:

1. “Show me one change from requirement through release.”
   Expect to produce a clean trace from intake to testing and sign-off.

2. “How do you ensure regulatory/security requirements are captured early?”
   They will look for required fields, required reviewers, and examples where security requirements drove testing.

3. “What prevents informal requirement changes?”
   They’ll test whether approvals and change history exist and whether scope creep gets re-approved.

4. “How do you know requirements are testable and met?”
   They’ll ask for acceptance criteria and mapped test results.

5. “Who owns this process?”
   If ownership is unclear, you’ll get findings even if teams “generally do it.”

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Requirements live in email/Slack	No control, no traceability	Centralize intake in one tool/repository and make it mandatory
“Security requirements” are vague	Testing can’t prove compliance	Write security/control requirements with measurable acceptance criteria
Approval is implied, not recorded	Auditors need evidence	Enforce workflow states with approver identity and timestamps
Traceability is manual and ignored	Breaks under time pressure	Build linking into the delivery workflow (templates, required fields, release checks)
Exceptions are tribal knowledge	Unbounded risk	Document exceptions with owner, rationale, compensating control, and expiry

Enforcement context and risk implications

COBIT is a governance framework; the provided sources do not include public enforcement cases tied specifically to BAI02. ¹ Your practical risk is still real:

• Audit findings (internal/external) for weak SDLC governance, poor change control, or inability to evidence control design/operation.
• Regulatory exam friction in regulated industries when you cannot show how obligations translate into tested requirements.
• Third-party and customer due diligence failures when you cannot demonstrate disciplined requirements-to-release traceability for security commitments.

Practical 30/60/90-day execution plan

First 30 days (stabilize and standardize)

• Appoint BAI02 process owner and publish RACI.
• Pick the system of record for requirements and implement a required template.
• Define approval gates and “no work starts until…” rules for in-scope changes.
• Pilot traceability on a small set of active initiatives (choose one app team and one platform/SaaS team).

Days 31–60 (make it operational)

• Expand intake and triage to all in-scope work streams.
• Add required links: requirement → work items → tests → release record.
• Train Product/PMs, Engineering leads, QA, and GRC on what “complete” looks like.
• Start monthly sampling: pick delivered changes and verify traceability completeness; document gaps and corrective actions.

Days 61–90 (harden for audits and scale)

• Add automated checks (tooling rules, required fields, release checklist gates).
• Formalize exception handling with risk acceptance workflow and expiry tracking.
• Produce an audit-ready evidence pack: procedure, samples, traceability exports, and metrics.
• If you use Daydream for third-party risk or control evidence management, map BAI02 artifacts to your control library so audits pull from one place rather than chasing teams.

Frequently Asked Questions

Do we need a separate “requirements document” for Agile teams?

No. You need controlled requirement records with owners, approvals, acceptance criteria, and traceability. In Agile, an epic/feature can serve as the requirement if it carries the required fields and links.

How do we handle regulatory or control requirements that apply across many systems?

Create reusable control requirement statements (a “requirement library”) and link them to each affected initiative. Track deviations as exceptions with documented risk acceptance and compensating controls.

What’s the minimum traceability chain auditors expect?

Requirement record → implementation work item(s) → test evidence → release/change record. If any link is missing, expect follow-up questions or a finding.

Who should approve requirements: business, IT, or security?

All three may be needed depending on the requirement type and risk. Define an approval matrix so teams don’t guess, and require security/GRC approval when requirements affect control obligations.

We buy SaaS; we don’t “build.” Does BAI02 still apply?

Yes. SaaS configuration, integrations, data flows, and access models still have requirements and control implications. Treat implementation and configuration changes as requirements-managed work with traceability to testing and go-live approval.

How do we prove BAI02 in an audit without drowning in screenshots?

Use system exports and immutable workflow history from your ticketing/ALM tool, plus a small set of well-chosen traceability samples. Keep a standardized evidence checklist per release so collection is routine.

Footnotes

1. ISACA COBIT overview

2. OSA COBIT 2019 objective mapping

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