Cybersecurity is a team sport. Not only does everyone have a role to play; everyone has to play together.
In a typical nonprofit organization, good cybersecurity requires the IT team to build and maintain strong internal and external tools and processes to identify and mitigate harmful behavior. It requires the staff to be mindful of emails they open and the information they send others, and it requires a board and senior leadership to regularly test and validate their response practices to ensure that every part of the organization knows their role if and when an incident occurs. Yet there is one more player on the team that is key to a strong cybersecurity posture, but one that is often overlooked – the nonprofit’s vendors and consultants. Vendors and consultants are as likely a target for hackers seeking to compromise donor data as the nonprofit organization itself.
As Chief Information Officer for a large nonprofit, I review almost every vendor contract my organization signs to evaluate the risk of sharing data with that vendor, and I have developed a short list of things that I am looking for. I share it now with the hope vendors will adopt this into their own thinking and our current and future vendors can be the team players we need them to be.
Maintaining PCI-DSS Compliance is a must for vendors. Independently verifying your compliance is even better. The best vendors perform annual, independent PCI audits. Taking the time to conduct an audit, and if possible sharing the results, signals to your customers that you are investing as much as we are into protecting our donors.
Updating your boilerplate contract language to include clauses about data ownership and data breaches. Failure to clearly identify who owns the data is the number one reason draft contracts get sent back to our vendors. The number two reason is that the contract does not contemplate how quickly the vendor will inform us if there is a problem. Having this language as part of your boilerplate builds trust because it shows that you’ve already thought through these issues. If on the other hand, you merely accept the language that is provided by your customer’s legal team, there’s greater risk that the protections requested were accepted by the legal team from a legal risk perspective, but have not been fully embedded into your actual operations. Coming to the table having thought through it all makes everyone feel better about the new relationship, and will speed the time spent in contracting.
Embracing the cloud and moving away from e-mailing files. I have seen many customer-vender operations premised on e-mailing a data file back and forth. The problem with this approach is that it creates multiple copies of the data file — one on the customer’s email server, another on the vendor’s e-mail server, and then wherever either side downloads the file when they use it. (Likely each team’s IT department will also create back-ups of their organization’s e-mail and files shares, creating more and more copies.) A better option is to use externally shared drives or secure FTP sites, where access can be controlled, and audited. The best option is to create systems that utilize APIs to share data. This will allow one team to directly pull from one organization’s system into another, eliminating the risk of copies altogether. All these options require trust, but importantly they limit the number of copies of critical data sets across both partners’ infrastructures. To your customers, riding on an API-based infrastructure also signals a maturity of operations.
Include your customers in your disaster recovery drills. More and more organizations are conducting annual exercises to practice their own response to a cyber incident. These exercises are great because they give the leadership team a chance to think through critical questions like, when do you tell your Board that there’s a problem, who has the lead on communicating to customers and who needs to sign off on what is being said, and how should your head of security expect to balance their time between incident response and being available to answer customer questions. It is far easier to think through these non-technical aspects of a cyber incident when you don’t have the adrenaline of a real situation coursing through your veins. What I have not yet seen in the nonprofit sector (but which was practiced during my days in the for-profit sector) is for customers and vendors to conduct such an exercise together. Cybersecurity is a team sport, and the team only gets better if it practices together. Conducting such a cross-organization exercise would require a down payment of trust and a bit of planning, but the mutual trust and operational improvement I wager would be ten-fold. A vendor who offered such an option as part of their offering would truly distinguish themselves in the eyes of their customers.
I too miss the days when cybersecurity was not a major concern for nonprofit organizations working to make the world a better place. But in reality, in today’s world cybersecurity incidents have real impacts on a nonprofit organization’s ability to meet revenue goals, communicate effectively with its constituents, and care for our employees. I know my colleagues in other nonprofit organizations are looking more and more closely at not only their own operations but at those of their vendors, looking to mitigate those risks. I trust that my friends who run the for-profit businesses that provide us critical services are doing the same.