One of the things that gets a rise out of hackers is a robust data breach policy. That’s because a decent data breach policy roadblocks a hacker’s sad little efforts and sense of self-worth. But a data breach policy is so much more than that. Let’s take a look at why you need a data breach policy and how to develop one.
Why You Should Get Yourself A Data Breach Policy
A data breach policy is your one source of truth for what happens if the worst happens. It’s the end product of some heavy thinking on how you should protect your business from cyber-attacks and what action you’ll take if you’re breached. It’s a crucial ingredient of your overall cybersecurity defense policy.
Often, a data breach policy isn’t required by law, but many cybersecurity compliance frameworks – like HIPAA – require procedures for reporting and responding to data breaches, which are covered by your data breach policy.
Here’s how the other benefits stack up:
What’s A Data Breach Look Like?
A data breach is a security event that puts sensitive, protected, or confidential information at risk of falling into unauthorized hands (or authorized-but-evil hands, with insider threats). Once breached, data can be stolen, sold, exposed, or used for blackmail. Nice, huh? Data breaches can happen because of:
- Insider threats. Disgruntled employees or contractors may use their permissions to access data for unauthorized purposes.
- Hackers. Attacks commonly appear as malware, ransomware, brute force, or phishing attempts.
- Unprotected devices. Bad things happen if someone gains access to a lost or stolen phone, laptop, or USB drive.
- Compromised third-parties. A person or system related to, but not part of, your company (e.g., a supplier) can put corporate data at risk – deliberately or not.
- Social engineering. Email impersonations can trick your people into revealing confidential information like passwords and logins.
A Robust Data Breach Policy: The Ingredients
One way of tackling the development of your data breach policy is to think of it in three chunks:
- The “Scope and management” chunk.
- The “What to do when it hits the fan” chunk.
- The “How we stop this happening again” chunk.
Scope and Management
Any good policy you can shake a stick at will have a framework that clarifies what it’s for, what it covers, and who does what. Your data breach policy is no different:
The Purpose: The Why
Here’s where you state the purpose of your data breach policy, such as to:
- Provide clear guidelines for responding to data breaches.
- Reduce the impact of data breaches on your business, customers, and other stakeholders.
- Provide evidence of compliance to regulatory bodies.
The Scope: What It Covers
With this chunk, you’ll clarify:
- What kinds of data and information are covered
- What you classify as a data breach – for instance, it’s good practice to include “near misses” as a data breach.
- The roles or departments it applies to – for instance, will it apply to the contractors you work with?
The Responsibilities: Who Does What
Here, you’ll outline who in your organization is responsible for which aspects of data breach response and mitigation. You may want to select an incident response team, a comms team and assign overall responsibility, at the very least. (Matching jackets optional.)
What To Do When It Hits The Fan: Incident Response
This is the juicy part of your policy and should outline how you spring into action if you’re breached. Each step of your response should have an action plan:
Safeguards: This action plan identifies the protections that should be in place to reduce vulnerabilities and prevent data breaches in the first place. You might link this section of your data breach policy to your overall cybersecurity policy or what’s covered by compliance frameworks like SOC 2 or PCI DSS if you’re accredited. Safeguards would be stuff like:
- Access control. Strong user identity management like multi-factor and biometric authentication, cloud single sign-on, and role-based access control.
- Data encryption. Ensures that data is unreadable as it travels.
- Regular updates and patching. A policy of “we always click yep” to “update now?” messages ensures that your people are working from the most updated, least risky software and operating systems.
- Firewalls and network security. You’re looking at things like intrusion detection systems, network segmentation, and application-layer firewalls.
Reporting: Identify the process and timeline for reporting a data breach or suspected data breach. An open, non-blame culture will make your people more likely to report breaches, even if they feel they may have made a mistake (hint: get them some phishing training!).
Communications: Once the breach is out of the bag, work out your lines of communication. Who are the people who need to know, and what information do they need to be able to carry out their responsibilities?
Response & Containment: Here’s where your response teams go into action to minimize any damage from the breach. Assess the scope of the breach and the potential damage. Isolate affected networks, data, or entry points. Shut down breached accounts.
Don’t forget to keep an eye on your legal responsibilities – you may have a duty to notify clients, suppliers, or compliance and regulatory bodies about the breach and security of data. Reputation management is key here, too.
How We Stop This Happening Again: Investigation and Remediation
After addressing the immediate breach, it’s time to prevent further damage and also strengthen your recently-discovered weak spots by eliminating those pesky attack vectors. You’ll do this through:
Investigation: Analyze exactly what happened and why. Conduct a post-incident review. Was the breach caused by a misconfigured device? Employee error? Perhaps a supplier’s system was at fault? Review and document your findings.
Remediation: What you do depends on the outcome of your investigation, but you might be looking at action items like:
- Phishing training to strengthen employee awareness.
- Reviewing your device configuration policy and monitoring protocols.
- Improving your offboarding process.
- Hiring vulnerability testing experts.
Data Breach Policy Development Is A Thing You Should Start, Like, Yesterday
But if you haven’t started yesterday, don’t freak out because, just by making the decision to a) create a data breach policy or b) dust off your old one, you’re being proactive. If you need an expert shoulder to cry/lean on as you knit up a solid data breach policy, give us a call. Tell us where you’re starting from, and we’ll nudge you in the right direction. Expert nudging is what we do. Amongst other things.
Ignition is Silicon Valley’s best (and friendliest) IT security, compliance, and support team. Contact us now – chatting about IT support and cybersecurity is our favorite thing to do!