Each of these elements can be expanded to provide sufficient detail to prospective users, auditors and other interested parties.

Evidence gathering is job No. 1 when developing an SSP. This can include system documentation, event logs, day-to-day security procedures, incident response plans and results of prior incidents, prior audit reports, interviews with system subject matter experts, vendor documentation, network documentation, and any other content that delineates system security controls and event response and mitigation activities.

Once legacy data and current data have been compiled, select a relevant SSP template. A template makes the SSP process much easier, and many are available -- both manual, fill-in-the blank ones and automated systems.

The IT security team governs how detailed the SSP should be, with support from the CISO and CIO. If the level of detail is likely to be significant, it could be worthwhile to retain an experienced outside party to assist with preparing the SSP.

During the course of SSP development, establish checkpoints to review progress and identify any issues that need to be resolved. Once the draft document has been completed, perform a QA/quality control check to ensure all elements have been identified, procedures have been accurately presented, controls have been defined and security resources have been identified. Ensure employees using the systems have been trained on security attributes.

SSPs, like many other technology plans and procedures, are living documents. It is ideal to schedule periodic -- e.g., quarterly -- assessments of the SSP and perhaps even more frequent mini-reviews among security technicians, vendors and users to keep the SSP current and relevant.