By Keith Lipman, president and founder of Prosperoware
Over the past year, we’ve seen an increase in the number of firms moving to need-to-know or pessimistic security for non-public data. The driver is simple: clients are demanding it. The underlying reasons are simple: (1) industry (such as finance) regulators are requiring it for clients’ data; and/or (2) clients’ security officers are demanding it as best practice. There’s also a simple truism of cybersecurity professionals: it’s not “if” a business will be hacked, but rather “when.” Law firms are in the unique position because most of the data they hold is owned by their clients.
The change to need-to-know security can be emotional and even scary for firms. Collaboration in legal today is dynamic and fast paced. Lawyers heavily leverage past work product for new work. Such a significant change may cause partners to worry about the impact on their ability to service clients. Meanwhile KM, Records, and Information Governance professionals worry about end-users avoiding document management and other systems if their ability to work is hindered. The fear is that if people cannot get access to the appropriate document when they need it, they will simply revert to saving elsewhere and sharing via email, defeating the entire system.
It’s therefore crucial to be aware of and understand the complete set of requirements before selecting or implementing a particular technology. It’s even more important to understand how people actually work in law firms – unless you don’t care about adoption or compliance.
Security Models Matter (Document, Profile/Metadata, or Rooted Container)
There are three different approaches to securing content: (1) document; (2) profile or metadata; and, (3) rooted container. Each exists in iManage and NetDocuments. These three approaches work quite differently. You need to understand how each approach secures content in determining your strategy for Need to Know.
Document Security
With document security, security is placed on each individual document. Typically, this is achieved via users or groups.
– Security changes take place at the document level
– Users can be granted or denied individual access subject to other types of security
– When documents are secured via a group, adding a user to that group provides instant access. Making changes to a large number of documents where security needs to be evaluated separately will take more time to complete.
Metadata Security
With metadata security, the security is placed on the client, matter, or other metadata (which is dependent on the system) that identifies the document. If you secured Matter X’s metadata:
– Any user that doesn’t have access to the matter will not see the matter number in look-up, nor will they find any documents
– Granting the user access to the metadata will provide access to all documents in that matter or client instantaneously
– On its own, metadata security is not capable of securing individual documents
– Metadata security is most efficient for denying access at the matter or client level
Rooted Document Security
All document management systems are designed with a rooted model. Both iManage and NetDocuments provide this at the library/database or cabinet level. By contrast, SharePoint offers this at the Site level. In the Windows file system, it is at the folder.
In the two most widely-used DMS for legal (iManage and NetDocuments), rooted document security is controlled at the top-level (e.g. database). However, for firms considering using SharePoint, it’s important to note that a user would need to first be given access to the site.
Understanding Ethical Walls / Information Barriers v. Need-to-Know Confidentiality
Whether you call them ethical walls or information barriers, there is a fundamental distinction between them and need-to-know security. Ethical walls were designed to be binary – a risk management tool that protects the firm itself from ethical violations. They are firm-centric, designed to address conflicts of interest, not client security. Decisions are typically made by the risk team at the onboarding of a lateral lawyer or a matter with a conflict. Access decisions are made and controlled by the risk management team.
Need-to-know security is client-centric. It requires a systematic approach to determining how clients want to control access to their non-public data. Determinations typically should be made on a per-client basis with the ability to provide tighter security controls when dictated by a client.
[table “1” not found /]1. Providing Flexibility for Securing Content and Self Service
Establishing need-to-know security should incorporate a rules-driven approach that provides options that enable a person to select appropriate access for groups of or teams. For law firms, the logical groupings are as follows:
– Matter Team
– Client Team
– Sub-department or Practice Group (of Matter)
– Department (of Matter)
This requirement tends to bring some very clear challenges for groupings:
It’s easy to identify initial members at new business intake; however,
Business services / admin staff likely will be mapped to fee earners
It becomes more complicated as matters progress
The process quickly becomes unwieldy as matters scale-up and teams are more matrixed
Practice groups and departments tend to be far more dynamic than the firm tracks
Sound challenging? It is. There are only two ways to manage: scale up the IT or Risk Team service desk (and provide 24/7 cover), or implement a layer of self-service that enables certain access decisions to be delegated to appropriate individuals or team members
2. Self-Service: Push or Pull (or both)
Delegating decision-making authority means deciding who can grant others access. This could be limited to risk officers only, the responsible lawyer, client/matter team, or even self-determined (think of this as closer to an ‘optimistic access, once requested’ model).
It’s also important to understand how access is gained. It can be via ‘push’ where a person authorizes and then delivers that access to another, or via ‘pull’, wherein a user seeking access will request that access and then an automated access request is sent to someone authorized to either grant or deny access. To enable scale, workflow-driven rules are crucial to ensuring a smooth, automated process.
3. Partial / Limited Access to Individual Documents or Folders
Imagine a typical litigation matter, or an M&A deal, or even a large corporate transaction – some pieces of work may require a specialist to review or complete. Whereas, in the past, there was little focus on security and confidentiality, it’s no longer in line with today’s clients’ expectations to grant access to everything in an entire matter to a specialist. Imagine there’s HIPAA protected PII, or GDPR covered ‘personal data’or any other non-public information. Full access wouldn’t meet the standard. In such instances, firms need a process in place to enable the sharing of individual folders or, better yet, documents without having to defeat the entire security around that matter or client.
For this requirement, only document level security works.
4. Granting Temporary Access
A common scenario today involves using associates, staff attorneys, paralegals, or ‘floater’ secretaries to temporarily assist on matters that they wouldn’t normally access. It’s the norm now that firms have professionals who are rarely limited to working within just one team, either to foster individual expertise or to create more flexible and cost-effective resourcing. Now, to maintain the client’s security posture, consider how the firm will provide access to a single document or folder or even an entire matter or client. That should be achieved while still ensuring the firm maintains a ‘least privilege access’ model.
Again, for this requirement, only the document level security model works.
5. Enabling People to Keep Documents Secure from the Rest of the Team
Partners maintain numerous sensitive documents such as those involving client or matter finances. Best practice dictates holding them as part of the client or matter file. However, due to their sensitive nature, it’s common to want to limit who can see them or even know of their existence within a file; they require tighter security than other documents in the file.
This level of granularity can only be accomplished with document level security.
6. Providing Access to Billers and Others for Specific Functions
Another practical consideration is how billers or other business services can operate across matters without having full access to all matter content (which would contravene client expectations). They need to be able to view and access very specific, limited content within a matter folder.
Document level security works best here.
7. Controlling a ‘Break Glass’ Solution to Providing Out of Hours Access
It’s no secret that lawyers work long hours. What happens when a lawyer or other professional needs access to secure data after hours? Is it reasonable to staff a support desk 24/7? One solution a firm I met with suggested was this concept of ‘break glass’. Their idea was to lockdown all matters and, in the event of an after-hours emergency, the person needing access could ‘break glass’ and gain immediate access, without approval first. This would be logged and then reviewed later.
Skipping the approval process may seem like a solution to the urgent need problem. Unfortunately, it’s a slippery slope as it inevitably slides from the occasional 3AM emergency to everyone ‘breaking glass’ at all hours of the day under the guise of urgency. No one will bother to follow the standard procedure or wait for formal approval if they can act first and apologize later. The idea quickly becomes unworkable. Someone will be left wasting a significant amount of timing ‘cleaning up’ after.
8. Keeping Public Data Public and Adjusting Security when Non-Public Becomes Public
What about when there’s too much security? Clients or regulations will dictate that matter data must be secured, but it doesn’t make sense to secure data that’s become public. This could include pleadings, court rulings, public filings, agreements filed with the SEC, etc. Because much of this information initially is private, there needs to be an efficient mechanism to accommodate the change – a fluid approach to confidentiality management.
9. A Client May be Clients and a Matter May be Matters
In numerous law firms, a client is typically represented through the use of multiple client numbers. This may be related to compensation issues or other factors. Similarly, a matter may be split across multiple matters numbers. This can also occur for a multitude of reasons, but it is typically related to differing fee types (e.g. hourly, fixed, etc). The end result is that a single team may need to have access to multiple client or matter numbers.
Balancing People + Process + Technology
You can’t make a decision about how to update security processes in a vacuum. As with almost any process, it’s crucial to understand and accommodate all three pillars of the ‘people + process + technology’ equation. Get one of them wrong and the project will likely fail. ‘People’ have only more recently been focused on this need for content security. It could be thanks to clients, cyber security awareness, or regulatory demands. The ‘process’ needs to be the next focus – and technology is closely aligned with process.
Before jumping in with any decisions, it’s important that firms understand the complex workflow and collaboration needs that their firm relies upon. Firms need to ensure that the technology selected can complement rather than hinder execution. If the software can’t support all these use cases, people will become frustrated. If they can’t get their work done within the defined process, people will find ways to get it done – likely by working around the DMS and content systems, negating the entire benefit of those systems and destroying any semblance of security.