top of page

Books and Their Covers

We're all familiar with the saying, "Never judge a book by its cover," and this holds up in information security as well as anyplace. Oddly enough, in information security, so does the inverse concept that we should never judge a cover by the book.

What this means is tied to both audits and incidents.

Just as a literary classic may have a damaged cover, an exceptional company you want to do business with may have suffered an incident. This single occurrence shouldn't remove them from consideration. One incident is, after all, a moment in time. Everyone experiences failures. What we should be concerned with is their handling of the incident and if it indicates a larger trend.

To evaluate a vendor in this situation, we're going to need to take a deeper look, which means going well beyond any SOC3 or STAR attestation. If the risk is significant and the deal justifies the effort, we want to sign some non-disclosures and dig into the controls and practices as well as their security efforts over time. We want to see that they are adequately mature, doing what we need them to do, and not a pretty cover masking a bad process.

And for the inverse, just because someone has a clean statement or attestation of compliance, does not mean the business is in good hands. While maturity assessments and audits over a time period are better, they do not indicate that the business is immune to security failures. There are no truly secure organizations, and all controls, no matter how perfectly designed, can be subverted. Our concern needs go beyond claims about security controls to examine how they deal with unexpected developments and failures of those controls.

How do we dig into this? By asking how they deal with failures in controls. Be specific. If the claim is regarding API security, discuss API failures and the aspects of incident identification and handling. Ask about testing and involve people that understand what is being discussed. Involving someone with audit experience is a good idea if the risk justifies the effort.

So if our third-party vendor risk management program involves checklists and doesn't look deeper than a security attestation, we may want to refine that process and drive evaluation to a deeper level based on business risk.

Add steps to look for incidents. Add questions about security practices over time. Invest the time and effort risk management demands, and don't use a one size fits all approach to third-party risk. Checklists can mask risk.

Every book is different, and a thin book with a bad cover might be a brilliant work of fiction, while a massive volume with institutional endorsements could be a waste of paper. Look past momentary criticisms and polished images because your business depends on selecting the right partner to enhance your competitive position.

3 views0 comments

Recent Posts

See All

Since the new trick pony showed up, I've been kicking the digital tires, and like many, I'm impressed. Not so much by the "AI" part, as by the sheer utility of it. Let's consider what's wrong with the

Insider security breaches occur far less often than either accidental disclosures or malicious outside activity (hacking), but they can pack a much bigger punch. Insiders are already within the first

Considering a merger? Here's a starting checklist for the cybersecurity components. An appropriate level of review now prevents surprises later. This is in addition to any IT considerations. Checklist

Post: Blog2_Post
bottom of page