As previously discussed, NCSA’s Advanced Computing Healthcare Enclave is undergoing a SOC 2 examination. This blog series will document our experiences, lessons learned and best practices.

During the initial drafting of our narrative and controls it became quickly apparent that a SOC 2 examination cannot be limited to security and policy staff. You will not have an accurate narrative of our system and organizational controls without the input, knowledge and experience of the entire organization. To ensure that everyone was on board and providing the information and input we needed, we assigned broad control categories to division heads and/or group leaders as appropriate. Collecting the controls and processes involved both security policy staff and the control group assignees. Moreover, this would also involve the individual staff who were most familiar with the implementation of these controls and processes, and the security staff who ensured that they were properly implemented.

Further, each control needs to be regularly tested. The reason for this is two-fold. First, internal monitoring provides assurance that our controls are operating as expected, and that we remain in compliance and mitigate risks. Second, the outputs of regular testing create a repository of documented evidence that controls are operating. This is especially necessary for the Type 2 examination, which assesses how controls are operating over a period of time. Collecting the evidence throughout the review period avoids a last-minute collection of documentation for all controls at the end of the review. The frequency of testing a particular control depends on how often the control operates (continuously, monthly, annually, etc.), availability of resources to perform the tests, and our risk tolerance. For example, we may choose to test newer or more complex controls more often than well-established controls we can better trust are operating.

Due to the sheer number of controls and staff, coordinating overall responsibilities and area ownership can very quickly get out of hand. NCSA’s approach evolved gradually from simple spreadsheets to collaborative tables in a wiki space to a custom GRC tool (of which more will be discussed in future posts). An example spreadsheet entry would look like:

While this could easily be done in a collaborative tool like Google Spreadsheets, it becomes difficult over time to track ownership, testing, and status of the controls. One reason is that it relies on either the control owner or tester to maintain the status of their respective controls within the spreadsheet. Another major factor is that spreadsheets do not enforce a workflow. For example, if a control is being tested and the test fails, then we must rely on the editor to properly annotate that control and set its status appropriately.

Another tool that can be used to track controls and processes is a collaborative wiki tool such as Atlassian’s Confluence. While a tool such as Confluence provides good integration with documentation for a control catalog, it only alleviates some of the problems described above. In the end it places the primary burden on the staff to manage their respective controls, which can lead to a messy situation in which controls are not properly tested or documented.

In the next post we’ll outline a workflow for how we’ve managed our controls and processes being examined during our SOC 2 Type 2 phase.