anyone dealing with this ? i have to help a customer and perhaps someone there has some expeirence and shed some light ? a compliance package?
the actual law:
who is in scope:
Operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the banking, insurance or financial services law. Small firms are excempted (under 10 people, 5 m in rev, etc)
it requires (now, but the list is planned to expand) based on the EY brief:
- a ciso
- risk assessment (including third party)
- have policies
- awareness trainings
- control definitions (and testing)
- the EY paper states pentestings are required, not sure this is a sales pitch from EY or the law says that too (need to read further)
- have security infrastructure (av, fw, encryption, etc)
- have incident handling procedures
- monitor known risks
- report once a year (something, not sure what)
As far as compliance package, in version 9.1 of the HITRUST CSF they’ve added mappings to 23 NYCRR 500. You could probably pull it from there. I had a client who wanted to add 23 NYCRR 500 to their HITRUST assessment but ended up waiting until the interim assessment to add it in.
Updated: 23 NYCRR 500 compliance package: https://dryve.cc/23-nycrr-500-regulations-controls-controls/
We’ve been helping a customer with the DFS implementation. The law is fairly straight forward in what it is asking for and I believe not all of the components are required yet (but will be). There’s a few FAQs on the NYDFS site that give a bit more information/guidance - for example, the annual report is the annual “Certification of Compliance” and it’s explained here.
Overview - https://www.dfs.ny.gov/about/cybersecurity.htm
FAQs - https://www.dfs.ny.gov/about/cybersecurity_faqs.htm
The pen testing has a bit of a loophole - if you have designed/implemented effective continuous monitoring, then a pen test is not required. Otherwise, it is - see Section 500.05 in the law.
What can be tricky with it is that there’s 2 ways to solve a problem in a lot of the clauses… but I suppose if you did a compliance package at the Section 500.xx level and then tied things out there it would work quite well.
I was thinking on you, because this customer of us contacted a company to help them and that company told them that what they needed is a SOC2 report … what you think?
this company has nothing (in terms of grc, policies, controls, etc)…my approach was to build and perhaps later on do a soc2 report … as doing a soc2 report when nothing is there is a bit of a waste of money, dont you think?
I suppose it depends on the context - it almost sounds like this is a company that has a customer that’s telling them they need to comply with DFS and are basically doing vendor management against them?
In general, the SOC 2 criteria provides a good start for a company going from zero to having controls. The DFS 500 regulation is NOT a complete framework, just a set of requirements that could be integrated into the SOC 2 criteria (i.e. design the incident response plan to include notice to regulators in accordance with DFS 500). If they had a successful SOC 2 audit, then that can help their customer complete their due diligence.
Now, whether it’s a waste of money or not is an interesting question. If the goal is to get to a Type 1 report (point in time or “as of date”), then it’s often structured to allow companies to do that - pre-assess that they have nothing, give them time to remediate and then go through and finish the audit. The Type 2 audit would be a waste of time because they would fail before the sample selections even started (and there’s not really an opportunity to fix in a Type 2 like there is in a Type 1).
Excellent feedback David - i’ll keep in touch , you are my man to go with SOC stuff.