Law firms have their place. Writing your security policies is not it.
By Ross Saunders
It sounds like a good idea. You’ve got a legal team on retainer, and they are completing a project for all your documents, so why not let them do your security and privacy documents too? Well, the fact is, Privacy and Security are specializations on their own, and this can lead to some pretty stark missteps in your policy implementation if they aren’t drafted to match your operations.
When it comes to policies, there is a distinct differentiator in the intention of a particular policy. Many policies, particularly those designed by law firms, are intended to be a legally defensible position should something go wrong. An insurance policy if you will. If something goes wrong, you can fall back on your policies and say that whatever happened was against company policy, and therefore you were justified in your actions.
While this is one of the reasons you would have a policy drafted by someone who is well versed in the law, that type of intention is being tested in the space of Privacy and Security. One of the interesting aspects of the privacy space is that there is the concept that a regulator can look at your operations to ensure they match your policies - the principle of “Accountability”. This changes the policy from a “fallback position” to an active “operational manual”. It’s no longer “what we say”, it becomes “what we do”.
Here’s where the trouble comes in. Your lawyers don’t know what you do. Yes, it’s a big generalization. And yes, there are lawyers that will take the time to understand your business. But, will they understand how the technical side of things actually works, and what is practical to your business? We see it over and over again where technical policies like an IT Security Policy has been drafted by a non-technical person - with wildly impractical (and indefensible) results. Below are a few of the things we see most frequently that could easily be avoided by engaging with technical specialists when drafting a policy.
Whose line is it anyway?
One thing that policies do (and this is your responsibility to check) is to impose obligations on team members. This is normal and to be expected. What we see very often though, is that the policies straight up refer to positions that don’t even exist within the organization. It’s fine and well having an escalation from the team lead, to the tech director, to the CTO, and then the VP of Technology, but do you even have these roles? Your policy should match the structure of your business, and take into account how your organizational chart operates. You can have the finest escalation policy in the world that means absolutely nothing if the roles aren’t there.
Expectation vs Reality
The next challenge is when the policy refers to activities and practices that are infeasible. We see this more frequently than the roles not existing in practice (far too frequently in fact). Your standards set in your policies need to be attainable. We’ve seen some gems coming from policies, such as:
All company owned equipment must remain on company property (so what was the point of that MacBook Air?).
All suppliers must be PCI-DSS compliant (considering this only applies to payment cards, you’re going to have a very short list of suppliers).
Staff are strictly prohibited from changing the format of a file (who needs to convert from Word to PDF, anyway?).
Network connections and sessions must be disconnected when you leave your desk (you mean I need to disconnect from wifi before I leave my desk?).
Prior written approval must be obtained from the CTO before any staff member may connect to the internet (wait, what? I thought we left the 90’s years ago).
These kinds of clauses illustrate quite well that you should be engaging with consultants that analyse your business and the subject matter at hand.
The 90’s called and they want their policies back
Speaking of the 90’s (and sometimes the 80’s and 70’s), many policies have been built off templates as old as the firms that designed them. This means that not only do you get a mishmash of dated language and weird paragraph numbering, you also get some entirely dated concepts included that have no bearing on your business.
References to floppy disks and microfilms are present and completely irrelevant for a modern start-up, yet public cloud services are conspicuously absent in many policies. We’ve even seen parking of hard drives mandated in policies, and if you’re old enough to know what this is, you probably haven’t done so since the early 90s at the latest.
More practically, and with far more material effect on your business, the same applies to dated password practices (please let’s ditch monthly password rotation already) and the lack of mention of great multifactor authentication methods such as FIDO keys. There are far more modern ways to protect your business and you want to leverage these (and someone who knows them), or at least provide room for them in your policies.
Much like a marketing document, you want your policies to actually be read and taken seriously by staff. Seeing terms like “a virus cannot be spread to another computer without human assistance” is utter crap*, and staff will call you on it and not read further.
(*This perhaps wasn’t hogwash prior to 1988 when the first worm came out. I think my point still stands though.)
So what’s the solution?
It’s not all bad. There are certainly times and places for lawyers, and we will absolutely and categorically direct you to one for many of your policies! But, when it comes to your technical policies, you need to have technical people writing them and regularly updating them.
There will be cases where “you don’t know what you don’t know”, and bringing in consultants with their finger on the pulse of different industries and standards is incredibly valuable. Involve your technical teams, and by all means have legal go over them afterwards, but don’t get drafted into an impractical box that doesn’t fit you.
