Planning for a System Security Plan

Many organizations today are involved with collecting and processing Personal Identifying Information (PII) or Personal Health Information (PHI). Because it’s crucial that such data is protected and handled properly, regulating agencies are requiring System Security Plans (SSPs) to be completed.

For example, the SSP template provided by the Centers for Medicare & Medicaid Services  (CMS) is described as “the current level of existing security controls within the System that protect the confidentiality, integrity and availability (CIA) of the system and its information.” The resulting SSP contains many other documents that address policy and procedure, and also provide evidence of implementation for more than a dozen groups, or “families,” of related security controls.

It would be one thing if responding to SSP requests was a “one and done” process. However, an SSP requires periodic review and adjustment to changes in hardware, applications, staffing and other factors, as well as fresh evidence of implementation. In addition, if your organization is involved in healthcare, insurance, or analytics, it’s highly likely that you will be required to respond more than once to requests from multiple agencies.

In other words, your SSP is an ongoing process — one with many pieces, including dozens of documents, data files, and screen shots. And this process can be a burden.

But it doesn’t have to be — not if you plan for your System Security Plan. Once you assemble an SSP team, deciding to do some extra work up front will make it easier on the team in the long run.

Here are four steps you should take when planning for your System Security Plan.

1. Share it. Store the SSP electronically and securely. Make it available to staff as appropriate — not just to the team collaborating to complete the SSP but also to those who will be using it to determine the supporting documentation that will be required. For ease of sharing, put your SSP on a trusted intranet site, such as a file server.
2. Store your sources. A good SSP requires documentation of the assertions indicating compliance with controls from NIST, HIPAA, or some other regulation, law or requirement. For example, an assertion may indicate that an audit log extract shows proper configuration to capture events as required. In this case, store the log extract with the SSP on an intranet site. Make it clear which control or step the log extract is used with, and write instructions on how to create another such extract, including the systems and programs needed (e.g., text editor) for the next time.
3. Commit to staying current. It’s not enough to create policy documents, which are almost always required with an SSP. You also need to show that these documents are reviewed and revised on a schedule (quarterly, annually, etc.). This clearly indicates that your organization is committed to keeping your security policies up to date.
4. Take (and keep) notes. When using interviews of staff or management as evidence of compliance, keep notes of the conversations, making it clear what questions were asked and how they were answered. Put the notes in an electronic format and store them with the SSP on an intranet site. This will save time when you respond to your next SSP request — instead of starting from scratch, review the previous notes, identify changes, and make any necessary updates. In addition, making the effort to produce and retain this documentation will demonstrate a real commitment to properly securing PII and PHI.

Thinking about a System Security Plan as an ongoing process will greatly improve the SSP and provide a way to address and improve areas where changes or updates are needed.