Diligent CCOs know by this point that they have some responsibility when it comes to the security of their firm and its information. Most are only too painfully aware that within the heading of security, they must be informed on the topic of cybersecurity. But from where does this impetus derive? A quick lesson on the development of this expectation will help the CCO understand their role going forward.
The concept of connecting the compliance function of an Advisor with complex technical processes was really instigated by the February, 2011 AXA Rosenburg case. In this action the Los Angeles office of the SEC clearly stated that the CCO should have understanding or comprehension of “quantitative models.”
This notion set off quite a bit of angst among overburdened Chief Compliance Officers who were suddenly faced with the possibility that their job description must now extend to include coding and programming in order to meet their 206(4)-7 requirements. Further, and while model errors did contribute to $217 million dollars in investor losses, the root of the enforcement was the mishandling or concealing of the error after the fact. As is often the case, it was not the actual event that triggered the action, but rather the perceived cover-up.
The SEC followed up on scrutiny in this area in its 2014 Exam Priority Letter making comprehension and controls surrounding quantitative models one of the listed “New and Emerging Issues and Initiatives.” There is more to discuss here regarding quantitative models, but from an overall technology standpoint, this is a point where many CCO’s realized that the game had changed:
- Any complex technical process, models, analytics, transaction algorithms, systems and applications relevant to the Portfolio Management and Trading Practices of your firm might be perceived to fall under the monitoring role of the CCO. As is often the case, a single area of focus like quantitative models may indicate a broader set of responsibilities, in this case many of which are connected to technology; and
- Errors and omissions involving technical systems and the handling of IT Security events vis-à-vis your firm’s Incident Response Plans are items of critical importance for the CCO. How such events are managed, documented, and reviewed in a post-mortem setting may set the tone for your next exam.
While AXA served as a vehicle for focusing attention on some high-tech processes, remember there are other, rule-based requirements which cover information security practices.
Pursuant to the Gramm-Leach-Bliley Act (GLBA), Rule 30 of Regulation S-P broadly calls for the adoption of “administrative, technical, and physical information safeguards” in the pursuit of protecting customer records and information. There have been enforcement cases related to Regulation S-P, most notably in 2011 when the SEC fined a brokerage firm’s president, national sales manager, and the chief compliance officer with respect to the removal of client account information to another brokerage firm. Once again, Regulation S-P has been more broadly interpreted to ensure that reasonable controls and information practices are in place to protect client information. Discussion of an additional amendment has been underway for several years, however elements of the suggested amendment may have been put in place by Regulation S-ID (Identity Theft) and the best practices suggested by the Cybersecurity Initiative.
In September of 2013, Regulation S-ID, Identity Theft or the “Red Flags Rule”, was extended to include SEC- and CFTC-regulated entities, covering most Registered Investment Advisers. If your firm is subject to the full scope of the rule there are critical requirements that must be understood:
- Your firm must have a Plan in place for Identifying, Recognizing, and Mitigating red flags or incidents related to potential identity theft. This element is actually the first formal call for an “Incident Response Plan.” As many IT security events (phishing emails, various scams and malware) are aimed at obtaining credentials, they would also be considered red flag incidents to be properly managed and recorded;
- The Rule also required due diligence of third-party vendors for whom identity theft may be an issue or possibility. This would equate to any vendor who maintains identity information of clients or employees, such as a Custodian, a CRM provider, a third-party client database, and so forth;
- You must have a methodology for logging red flag incidents, which should include resolution and lessons learned from events; and
- CCO’s must add training related to identity theft to the already long list of topics to be covered, however we would mention that it is possible to include ID-theft issues with general cybersecurity awareness training.
We would be remiss not to mention under consideration of existing requirement related to cybersecurity, the critical concept of “fiduciary responsibility” which is often stated as a basis for business continuity management. This same notion should be applied to IT Incident Management or Response and Recovery Plans, as we are discussing forms of potential disruption for the business.
The Cybersecurity Sweep Document Request of April, 2014 and the ensuing NEP Alert of February, 2015 have provided some guidance for information practices which should be considered at your firm. The statistical NEP Alert provided a benchmarking document, allowing a CCO to compare their program with that of their peers. However, it didn’t directly discuss the criticality or importance of specific cybersecurity elements. While each firm and CCO must tailor their program to meet the specific needs of their business, we recommend that both documents that should be put on the table, examined in the context of your firm’s risk management program or, at a minimum, worked over by Compliance and IT in conjunction.
The SEC’s 2015 Exam Priority Letter mentions Cybersecurity under “Assessing Market-Wide Risks.” At the very least, we would recommend that the CCO consider Cybersecurity in their Annual Review process and obtain a level of confidence in the controls in force to meet the firm’s requirements under the aforementioned rules. While the CCO is not required to be a programmer they should, at the very least, take the time to tie the aforementioned regulatory expectations to their firm’s security program.
If you would like more information on the Sweep Summary, please review our recent white paper:
“Five Statistical Observations” related to the Sweep Summary.
Please contact Artemis for assistance in addressing IT security, including Response and Recovery Plans, at your firm.
Further Reading (Links Will open in a new window):
SEC’s Press Release Regarding AXA Roesnberg
2014 Exam Priority Letter (Quantitative Models)
Cybersecurity Sweep Document Request
