Project Initiation, Business Case, and Chartering
Domain 1 tests the front end of a security project: turning a threat, audit finding, or compliance obligation into an authorized, funded project with a named sponsor, a defensible business case, and a charter the project manager can actually manage against. (The source does not publish domain titles, so each section here is named by the content it examines.)
What initiation must produce
- Business case - the security risk or regulatory driver, options considered (including doing nothing and the residual risk that implies), a rough order of magnitude cost, and the expected risk reduction.
- Project charter - approved by the sponsor, not the project manager. It names the PM and delegates authority, states measurable objectives and success criteria, sets high-level scope boundaries and exclusions, identifies key milestones and budget authority, and records approval requirements.
- Stakeholder register, first pass - sponsor, facility owner, security operations, IT/network, legal and privacy, EH&S, procurement, the authority having jurisdiction (AHJ), the integrator, and the people who will use the system.
Constraints, assumptions, and the project/operations line
Constraints are fixed limits: a budget ceiling, a go-live date tied to a lease or audit, a mandated standard. Assumptions are conditions believed true (existing conduit is reusable, network drops are available) that must be validated and logged. Recurring work - guard tours, alarm monitoring, patching video management servers - is operations. It belongs in the transition-to-operations plan, not in project scope.
Worked example
A data center must have video coverage of a new cage row before a customer audit in 14 weeks. The sponsor asks for "AI analytics." The audit date is a constraint; the driver is documented coverage evidence; analytics does not serve that driver. The charter objective becomes: documented coverage of the cage row with 90-day retention, verified by the security director and audit liaison. Analytics is logged as a future-phase assumption, not scope. Writing the objective in measurable terms is what makes later acceptance possible.
Traps
- Treating the charter as a detailed scope statement, then arguing requirements before the project is authorized.
- Accepting a budget figure with no stated contingency or escalation authority.
- Leaving out the AHJ and legal/privacy, so permitting or a privacy impact assessment surfaces during installation.
- Objectives that cannot be tested (improve security) instead of criteria that can be.