Cyber security and law firms: Don't just do it!

The shiny allure of technology is so enticing, and the sales-siren’s call, “Just buy this thing and all your pain will go away” is almost irresistible. 

But for law firms, cyber security is rarely a problem that can be solved with technology alone. Legal practices handle highly sensitive client data, confidential communications, financial records and high-stake legal matters, making them prime targets for cybercriminals.

In short: cyber security for law firms demands a strategic, risk-driven approach: Strong governance, operational security and compliance… not just the shiniest tools.

For law firms, cyber security is rarely a problem that can be solved with a single product. Legal practices handle highly sensitive client data, confidential communications, financial records and high-stake legal matters, making them prime targets for cybercriminals.

Of course, with the proper approach, various technologies really can help firms to manage their level of risk by offering capabilities such as automated real-time threat detection, intrusion prevention, and response mechanisms, allowing firms to proactively protect their clients’ data and their own reputation. But, before you whip out the credit card, it’s important to step back and take a deep breath. 

Siiiiigh! 

Now (mind cleared and sales-excitement banished) consider two points:

1)  Firstly, has your firm developed an initial set of prioritised, risk-based, cyber security requirements?

2)  Secondly, does the technology that you are considering fit in with and address those requirements?

So, you’ve confidently answered ‘yes’ to those two questions, right? Well, then then you must have read this article, and so you’re definitely on the right track! You’ve done your homework, completed a risk assessment, and used that to figure out your priorities. That’s the way to do it! Now, you can invest in technology with a clear conscience and confidence, knowing you’ve made decisions based on solid groundwork.

Cyber tech can assist and some tech will almost certainly be required in order to secure most law firms; but even so, don’t just rush for tech! Instead, develop a prioritised set of risk-based requirements, and then select the most cost-effective tech that meets those requirements.  This approach will ensure that your firm allocates resources strategically, focusing on the most critical security threats and vulnerabilities specific to its operations.

Why does cyber security remain a significant risk?

Cyber security remains a significant risk for some law firms for a couple of reasons.

Firstly, law firms are an attractive target and the size of the firm doesn’t really matter. In 2023, the Cl0p group breached Kirkland & Ellis, K&L Gates, and Proskauer Rose in the US. In Australia we continue to read about HWLE’s 2023 breach, most recently in the Feb 21 announcement that the OAIC “has commenced an investigation into the personal information handling practices of HWL Ebsworth Lawyers (HWLE), arising from a data breach notified to the Office of the Australian Information Commissioner (OAIC) on 8 May 2023.” And there was the interesting Nov 27 update in the AFR that, “Russian hacking group LockBit has removed a listing threatening to release data stolen from law firm Allen & Overy, in a sign the parties may be negotiating a ransom payment.”

Secondly, cost is an important consideration especially for boutique and SME firms that do not generally have the budgets available in larger firms. There is also a perception that due to budget constraints, smaller firms are a more attractive target for cybercriminals, and various on-line publications back this up. For example, one report mentioning the American Bar Association stated that while 20% of survey respondents (law firms in the US) overall reported having breached, in firms with 10-49 attorneys, this figure was nearly twice as large, at 35%.

As outlined above, effective security measures can only be successful if we first establish an initial set of prioritised, risk-based requirements. This risk assessment will guide law firms in understanding their specific vulnerabilities and threats, allowing them to allocate sometimes-scarce resources wisely.

With this foundation in place, law firms can then invest in the necessary technology and expertise to protect their client confidentiality effectively, as well as adapt to the evolving landscape of cyber threats.

Are you saying I need to be an IT expert as well?

No, here’s the thing. You don’t need to be a cybersecurity expert to run a law firm. Law firm owners and partners do not (in general) have the time to become cyber security practitioners. And that’s fine as long as owners and partners have enough of an overview to be able to engage with experienced and pragmatic practitioners to understand how technology aligns with their initial set of prioritised, risk-based requirements.

And to detect the smell of bull when they are being fed tech for its own sake.

Partners, directors and owners who are serious about managing their organisation’s risks will be seen raising the security bar and leading by example, because only they have the authority to set the cybersecurity direction for their organisations. By understanding cyber risk (perhaps with the assistance of subject matter experts), partners, directors and owners can communicate the importance of cyber security to their staff, fostering a culture of security consciousness that aligns with the identified risks.

In the end, it’s about protecting your clients’ data, preserving your firm’s reputation, and meeting your obligations as a business owner. And that, my friends, is a job worth doing right.

What is PCI DSS?

The PCI DSS is the Payments Card Industry Data Security Standard. The PCI DSS covers two kinds of sensitive data:

  • Cardholder data – primary account number (PAN), cardholder name, expiration date
  • Sensitive authentication data – PINs, security codes, etc.

The PCI DSS applies to:

  • Merchants – Businesses that accept card payments from customers (online, in-store, mobile, or otherwise)
  • Third-party service providers (TSPs) – Organisations that handle or could impact the security of cardholder data on behalf of merchants.

If you handle this data, or if your service provider does (on behalf of your organisation), you are bound by PCI DSS requirements. dotSec is an Australian PCI DSS company and and in this post, we’ll help you to understand how to reduce your PCI DSS-compliance reporting load. 

What is a pci dss merchant?

A merchant is an organisation that accepts payment from a cardholder when the cardholder purchases goods or services. This isn’t just limited to online businesses. It includes businesses with point-of-sale (POS) terminals as well. Whether transactions occur online, in a physical store, or via a mobile device, the organisation accepting payment is considered a merchant. 

Each of the PCI DSS card-brands (Visa, Mastercard, etc.) categorises merchants into four groups depending on how many transactions the merchant processes per year, and the amount of compliance work that needs to be done by the merchant in order to be compliant with the DSS depends on how many transactions the merchant processes.  

Here is Visa’s categorisation chart, for reference:

Level 1.

Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region.

Compliance requirements: 

– Annual Report on Compliance (ROC) by Qualified Security Assessor (QSA)

– Quarterly network scan by Approved Scan Vendor (ASV)

– Attestation of Compliance Form

Level 2.

Merchants processing 1 million to 6 million Visa transactions annually (all channels).

Compliance requirements:

– Annual Self-Assessment Questionnaire (SAQ)

– Quarterly network scan by ASV

– Attestation of Compliance Form

Level 3.

Merchants processing 20,000 to 1 million Visa e-commerce transactions annually.

Compliance requirements: 

– Annual Self-Assessment Questionnaire (SAQ)

– Quarterly network scan by ASV

– Attestation of Compliance Form

Level 4.

Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually.

Compliance requirements: 

– Annual Self-Assessment Questionnaire (SAQ)

– Quarterly network scan by ASV, if applicable

– Compliance validation requirements set by acquirer

Acquirers, merchant agreements and reporting

First up, let’s talk about acquirers. An acquirer is generally a bank that provides merchants with the ability to accept card payments. They also settle transactions, which means they transfer money to the merchant after a transaction is completed. While acquirers are often banks, it’s worth noting that other parties can also act as acquirers or at least function in a similar capacity.

In the world of PCI DSS, each merchant and it’s acquirer (or payment processor) are bound by a merchant agreement. The merchant agreement outlines the obligations of both parties, particularly regarding the protection of customer cardholder data. If you’re a merchant who has access to or stores card details in any format, it’s your responsibility to ensure those payment details remain secure. Many merchant agreements point to the PCI DSS guidelines for more detailed information on compliance requirements. However, they often provide some initial guidance on what level of compliance the merchant falls under and how they need to report their compliance

Reporting requirements

Generally speaking, all merchants have reporting requirements, irrespective of their level. However, the specific requirements differ. Most merchants, except for the highest level (Level 1), are typically required to complete a Self-Assessment Questionnaire (SAQ). Level 1 merchants, on the other hand, usually need to undergo an annual assessment by a Qualified Security Assessor (QSA).

For the bulk of merchants, the key to PCI DSS compliance is the Self-Assessment Questionnaire (SAQ). Different SAQs exist, each tailored to different types of payment processing environments. The specific SAQ a merchant needs to complete depends on how they process card payments.

All merchants except Level 1 merchants need to complete an SAQ. Level 1 merchants need to undergo a QSA annual assessment and produce a report on compliance (ROC).

Side note: If you’re a Level 1 merchant, this post is not for you because you cannot report using a SAQ. (We can of course provide your QSA-led assessment, AOC and ROC, but that’s not part of this post). 

For all other merchants:  You want to reduce your SAQ reporting requirements as much as possible (because that will save you time and money) and this post is most definitely for you!

An important question arises: Must merchants voluntarily submit their SAQs, or do they only need to have them available if requested? The answer depends on the acquirer. Some acquirers have portals through which merchants must submit their SAQs. This makes the submission process easier for merchants, as it often involves a wizard format to fill in the information. However, some acquirers may not actively ask for the SAQ. 

Regardless, merchants are still required to complete an SAQ and an Attestation of Compliance annually, even if no one asks for it. The merchant should have it ready if and when requested.

Selecting the right SAQ to reduce your reporting load

Selecting the correct SAQ is crucial unless you want to waste money and time on unnecessary reporting. Merchants need to (and yes, dotSec can help here) determine which SAQ applies to them based on their cardholder data flow and review their data flow against the eligibility criteria in each SAQ. The SAQs themselves have the eligibility criteria listed before the questionnaire. So in general, we can determine which SAQ applies to a merchant based on their cardholder data flow and by reviewing the data flow against the eligibility criteria in the SAQs.

Aside: When discussing SAQs, it’s important to distinguish between questions and controls. A control is a security measure designed to protect cardholder data. A question in the SAQ is used to verify whether a particular control is in place. You might think that the number of questions would equal the number of controls, but that’s not necessarily the case. A single control may relate to multiple questions. 

For example, a control related to access controls and identity management may require answering multiple questions to ensure full compliance. Conversely, to comply with a single control may mean answering a number of questions.

The golden prize: Reporting under SAQ A!

SAQ A (Self-Assessment Questionnaire A) is the leanest of the PCI DSS reporting paths, meaning that it can be used (in general) with very little effort or time. 

Merchants prefer SAQ A because there are only 26 controls (and some of those might be non-applicable) and it’s often possible for the merchant to offload many of it’s  PCI DSS responsibilities to third-party providers such as payment gateways or security service providers, as long as those third parties are themselves PCI DSS compliant.

To be eligible for SAQ A, all cardholder data functions must be fully outsourced to PCI DSS-compliant TSPs, and merchants must:

  • Not store, process, or transmit cardholder data on their systems
  • Use only redirects, iframes, or hosted payment pages
  • Confirm their ecommerce site is not susceptible to script-based attacks. 

So what are the steps to reporting under SAQ A?  Not a real lot as it happens:

1) Check your transaction volume

If you process fewer than 6 million transactions annually, you’re probably not Level 1 and that’s good news! You might be eligible to self-assess (i.e. Report using a SAQ, preferably SAQ A)

 

2) Confirm your eligibility for SAQ A

Check the following:

  • Have you confirmed that any account data the merchant might retain is on paper and these documents are not received electronically.
  • Do you fully outsource payment functions to PCI DSS-compliant third parties?
  • Can you confirm that your system does not store, process, or transmit cardholder data?
  • Have you taken steps to ensure that your ecommerce site is not susceptible to script-based attacks? There are two ways to do this: Either get written confirmation from your third-party provider that scripts are secure, or implement SAQ A controls 6.4.3 (secure management of scripts on payment pages) and 11.6.1 (tamper detection for payment-page scripts).

You’ll need to answer “Yes” to all of these if you want to report under SAQ A.

 

3) Get evidence from your providers

If you rely on third parties (e.g. for web hosting, payment pages, scripts), ask for their Attestation of Compliance (AOC) or SAQ. If they cannot or will not do that, get rid of them! If you use a non-compliant third-party, not only will your dreams of SAQ A quickly fade, you may find yourself in SAQ D hell, reporting on 252 controls at best, or non-compliant at worst!


4) Complete the SAQ A

Fill in the questionnaire, mark inapplicable questions with justification, and retain your Attestation of Compliance. Some acquirers require this to be uploaded to a portal; others just need it on hand. Do it before you’re asked! Waiting for your bank to remind you is a risky strategy. If they ask and you’re not ready, you’ll be scrambling—and that usually means extra cost, confusion, and mistakes.

We know pci dss in australia

dotSec stands out among other PCI DSS companies in Australia for a couple of important reasons:

  • We’re a PCI DSS-compliant service provider and we have an AOC to prove it!  We don’t just talk the PCI DSS talk, we’ve walked the compliance walk, so we know what it takes to implement and maintain a compliant PCI DSS service.  
  • Our PCI DSS professionals have a wide range of certifications including QSA, ISO 27001, CISA, CISM and more.  We’re not just a one-shot, tick-the-box QSA assessor company. 
  • PCI DSS compliance recommendations are practical, based on our actual, boots-on-the ground implementation and compliance experience.  We’ve picked up after less experienced QSAs who have confused the client with mistaken controls, incorrect SAQ selection and impractical compliance recommendations; no one needs those kinds of problems on top of an already-demanding compliance program of work. 

If you’re aiming to report under SAQ A, don’t wait for your acquirer to come knocking. Your obligation to maintain PCI DSS compliance is defined in your merchant agreement; not in a reminder email. The sooner you assess your eligibility, confirm your third-party dependencies, and secure your ecommerce environment, the smoother and less costly your compliance journey will be.

Need help figuring out your eligibility or navigating SAQ A? 

Contact us today for expert guidance and support in navigating SAQ A and beyond. We can help you map your data flows, check your third-party evidence, and make sure your SAQ stands up to scrutiny so you’re prepared when the bank comes knocking.

OUR CYBER SERVICES