Introduction
Software vendors are not born into the world with highly mature and secure security systems and practices. Indeed, vendors are usually born into the world as a startup with a vision, and a short-timeline to making that vision a reality.
Vendors in early stages of their life will most likely have spent their time developing features and functionality rather than focusing on security systems, processes, and tooling. Security profiles are usually created as vendors mature in the market, and as vendors mature as software companies in their own right.
By monitoring the actions and interactions on your network–a password change, say, or a data download–log monitoring systems can identify irregular or suspicious activity and can flag potential security breaches before data is exposed, or contain exposure quickly.
Look for providers who are eager to discuss their data security policies and practices at any stage of your evaluation. Transparency is key. A good vendor relationship is built on trust and on a mutual understanding of how each party will behave, both to protect your data in day-to-day operations as well as if a security incident occurs.
8 Questions to Ask Your Ediscovery Vendor
- Which compliance credentials do you have?
Credentials like SOC 2 Type 2 ensure that your vendors are compliant with basic standards of privacy and security. Credentials require a standard of systems, processes and tooling to achieve. A vendor that has the credential has demonstrated that they have met the standard.
- How often do you perform penetration tests?
Penetration tests (PEN test) are performed by a third-party test company. During a PEN test, the test company will attempt to exploit known vulnerabilities in a vendor’s software systems to try to gain access. PEN tests are critical for vendors to learn and fix weaknesses caused by new or emerging vulnerabilities. They should be performed at least annually. - Is data in your platform encrypted both in transit and at rest?
Data that’s stored in a database is called data “at rest.” Data that’s moving between databases is data “in transit.” Think of the database like the data’s home. That’s where it lives. And the transit is how the data moves between locations. Data is exposed in different ways, depending on whether it’s moving or if it’s happy in its bed at home. Encrypting both in transit and at rest ensures that whatever your data is doing, it’s protected.
- Who will have access to my data on your platform?
Vendors working with sensitive information should follow the rule of least privileged, that is, an employee will have access to data only if that data is needed for the employee to complete their job. What this means in practice is that only a subset of any vendor’s employees will be able to access the storage or transit areas of the vendor’s technology stack. This reduces the number of humans who could potentially be compromised by a user access breach, and also a malicious actor breach.
- What types of information are logged, and how long are logs available?
Every part of a vendor’s network creates a list of every action that happens in that network. The list is called a log, and every item on the list is an interaction point. By monitoring the actions and interactions on your network–a password change, say, or a data download–log monitoring systems can identify irregular or suspicious activity and can flag potential security breaches before data is exposed, or contain exposure quickly. In addition, logging is critical to see what data was exposed in the event of a breach, allowing both the vendor and the customer companies to take the right and necessary steps, including notification to customers about the exposure profile as well as corrective action to fix the vulnerability point. Logging should generally be available for 90 days, with an outer bound of 12 months. The amount of data stored in logs can itself be massive, so finding the balance between logging and storage is important. - What is your incident response plan?
We all hope never to have a security incident, but hope is not a plan. If one happens–and increasingly, that “if” is a “when”, it is critical that your vendor has documented steps to follow. The response plan usually includes six stages: preparation, identification, containment, eradication, recovery, and lessons learned. The preparation stage itself includes things like employee training and run-throughs of key steps in the process, like testing fail overs or backups. The plan is simply an articulation of how your vendor will respond in the event of a security incident. Without a plan, there is chaos. With a plan, there is an ordered and thorough response to contain and recover from an incident. - How do you support your customers and how good is your support
Your relationship with your ediscovery vendor is a partnership. Support encompasses everything from helping you set up your workflows and templates, to solving large spike needs, to unblocking you when you get stuck. Vendors who excel at support will create better outcomes for your legal and ediscovery teams, while vendors who leave you in the dark will create frustration and eventual failure.
- What happens to my data if I choose to stop taking your services?
A breach to your vendor’s systems is a breach to your own. As long as your data is stored in a vendor system, you are at risk. If you leave a relationship with a vendor, you need to be sure all of your data is purged from the vendor’s systems. Some vendors treat this final step in their customer relationship as an afterthought. It’s critical that the vendor purges all of your data. The last thing you want is breadcrumbs–or big stores–of data littered through the vendor ecosystem. This creates more exposure and more risk overall.
