How to build an SSDLC.

Put the SSDLC into operation

1. Establish the mandate. Copy the programme charter. Name the sponsor and owner, identify the systems and work in scope, and record the authority and resources available.
2. Record your choices. Copy the adoption procedure and register. For each document or clause, choose “will do”, “won’t do” or “deferred until”. Leave an undecided item explicitly unresolved. Record the reason, owner and decision authority.
3. Identify the people and their needs. Use the stakeholder register and responsibility schedule. Include the people affected by the system, not only its delivery team. Roles describe work and authority; they do not prescribe a staffing minimum.
4. Copy the operating documents you adopt. Complete the square-bracket organisation fields and keep the procedure text. Use the shared setup record for names, locations and parameters repeated across documents. Approve your organisation’s version through the authority you established.
5. Put the work on a schedule. Activate the relevant entries in the schedule and trigger register. Name who detects an event, who performs the work, what result is recorded and who receives an overdue or failed activity.
6. Assess the promises. Copy the assurance programme. For each adopted promise, identify the evidence and assessment method. Use the management review and corrective-action procedure to decide what to do with the findings.

What to fill in, and what to keep

The documents contain actual policy and procedure wording. Square brackets mark organisation-specific information: names, system boundaries, authority, dates, criteria, contacts and record locations. Fill those fields from your decisions. A blank risk tolerance, response period or retention period is not a hidden default; the responsible authority needs to set it for your organisation and its obligations.

You can adopt a whole document or make a clause-level choice. Record the choice and keep the resulting version consistent. “Will do” records a commitment, not a claim that the work is already operating. “Won’t do” preserves the decision and its consequences. “Deferred until” identifies a date or observable event, an owner and a review arrangement. None of these choices silently changes an external obligation.

The record templates are intended to be duplicated for your actual work. They contain no fictional organisation and no completed scenario to remove. Keep their identifiers and relationships so a requirement can point to its stakeholder source, a change to its authority, and an assurance conclusion to its evidence.

Use the library across the system life cycle

For a new system, the charter, stakeholder records, life-cycle plan, risk procedure and requirements records establish the starting position. Architecture, threat modelling, resilience and acquisition then connect protection needs to design and supplier decisions. The development, verification, change and release documents govern delivery. Operations, vulnerability response, incident response and retirement carry the same responsibilities beyond release.

For an existing system, record the present scope, owners, configuration, dependencies and operating decisions. Assess which adopted activities are already performed and where evidence is missing. Record implementation work without claiming that the system’s earlier history followed a policy adopted today. Existing useful records can be linked rather than rewritten.

Privacy and information management apply wherever the system processes information about people. AI documents cover assisted development, acquired services, integrated AI systems and model development. Select the activities your organisation performs and retain the limits of supplier visibility in its decisions. The library includes technical evaluation and authority boundaries as well as stakeholder and management responsibilities.

Assurance measures the promises you made

The connection throughout the library is: stakeholder need, adopted promise, assigned responsibility, operating procedure, schedule or event, evidence, assessment and decision. You can keep these in one register or several linked registers. What matters is that someone can follow the connection and determine what was promised, what happened and what the evidence supports.

A completed policy document is evidence of the policy decision. An operational record is evidence of an activity. An assessment explains whether the evidence supports fulfilment of the promise and, where assessed, the intended outcome. The templates preserve missing evidence, failed activity, accepted risk and work that was not due as distinct positions. This makes management review usable for decisions rather than merely producing a favourable score.

A common language, with the source relationships visible

SP 800-53 Rev. 5 supplies common control identifiers. The library also uses CSF 2.0, the Risk Management Framework, Privacy Framework, NICE, supply-chain risk management, SSDF and its AI profile, and the systems engineering and resilience publications in SP 800-160. ISO/IEC/IEEE 15288:2015 is the life-cycle foundation. ISO 31000:2018 informs the risk language, and the AI management content provides a route to considering ISO 42001 relationships without republishing the standard.

The framework reference document identifies editions, selected published crosswalk pairs and the library’s editorial mappings. It includes SSDF practice coverage and NICE role references. A mapping helps translate the work; the organisation’s implementation and evidence determine what it can claim.

From manual operation to Caedist

You can operate this library using your existing repositories and people. Caedist is the mechanised SSDLC: it is intended to connect organisational intent, authority, engineering work and evidence in the operating environment. The manual library makes the underlying work available to adopt and examine.

See how Caedist connects the life cycle · Contact Caedist about the capability