Skip to main content
Industries · Legal

Confidentiality is the product

Clients do not retain a firm because of its document management system. They retain it on the assumption that what they share stays privileged — and increasingly they audit that assumption before instructing.

AIPTx tests the systems holding it, and produces the evidence the audit asks for.

A locked case of confidential client files under a lit shield, with a document open under a magnifier and the assurances an instructing client audits for (access control, data privacy, secure storage and audit evidence) checked off beside it.
01

Industry overview

Law firms hold concentrated, high-value confidential information and have historically invested less in protecting it than the organisations that give it to them.

The material is exceptional in both value and sensitivity: merger and acquisition plans before announcement, litigation strategy, intellectual property, regulatory investigation material, and personal information disclosed under privilege. A firm advising on a transaction holds information that is directly monetisable in a way that most corporate data is not. Firm structure adds a distinctive problem. Partnerships are not hierarchies.

Technology decisions are made collectively, security investment competes with distributable profit, and a partner who wants to work a particular way is difficult to overrule. Information barriers between matters are a professional obligation, and enforcing them in software is an authorisation problem of real complexity.

What has changed most recently is client behaviour. Corporate clients now issue outside counsel guidelines with specific security requirements, run vendor assessments on their law firms, and in some cases require evidence of testing before instructing. Security has become a condition of being retained.

02

Security challenges

  1. R01

    Information barriers are an authorisation problem

    Ethical walls prevent one team from accessing another's matter. Implemented in a document management system with decades of accumulated matters, exceptions and inherited permissions, they are exactly the kind of complex authorisation model where failures hide.

  2. R02

    Client portals and data rooms

    Firms increasingly share material through portals and hosted data rooms. Cross-client access in one of these is a professional catastrophe, not merely a security incident.

  3. R03

    Small or absent security function

    Many firms have an IT team and no dedicated security staff. The capacity to run a security programme, triage findings and maintain evidence is genuinely limited.

  4. R04

    Client audits arrive with deadlines

    An outside counsel guideline requires evidence of testing, or a client's vendor risk team sends a questionnaire during a pitch. The response affects whether the firm is instructed.

  5. R05

    Document management systems are the crown jewel and the legacy system

    Frequently the oldest core application in the firm, holding everything, integrated with everything.

  6. R06

    Highly targeted attackers

    Firms advising on transactions are targeted specifically, by parties with a clear financial motive and knowledge of exactly what they are looking for.

  7. R07

    Partners as a high-value target group

    Senior individuals with broad access, high mobility, and limited tolerance for security friction.

03

How AIPTx helps

  1. Stage 1

    Information barriers tested by attempting to cross them

    Configure accounts on different matters and different teams, and the agent attempts cross-access while holding both sessions. A user reaching a matter they are walled from is an authorisation failure that only surfaces when two identities are compared, and it is the single most important thing to test in a legal environment.

    Web Application Security
  2. Stage 2

    Client portal and data room assessment

    Multi-role authenticated testing across client, fee earner and administrative accounts, with cross-client access attempted. Where a portal serves multiple clients, isolation between them is tested the same way a SaaS product's tenant isolation would be.

  3. Stage 3

    Testing that does not require a security team to operate

    Findings arrive confirmed, with the exact request, the response proving it worked, a reproducible curl command, and remediation guidance including vulnerable and secure code examples. For a firm without dedicated security staff, this is the difference between a report that gets actioned and one that gets filed.

  4. Stage 4

    Evidence formatted for a client audit

    Reports include an executive summary, technical detail, control mapping for ISO 27001, SOC 2, GDPR, NIST, CIS and PCI DSS, and trend comparison against previous assessments, exportable as PDF, HTML, JSON, CSV or SARIF. When a client's vendor risk team asks, the answer is a document rather than a project.

  5. Stage 5

    Internal assessment of the systems that hold the material

    The Docker-deployed agent covers internal IP ranges and CIDR blocks with outbound connectivity only, providing service, version, CVE, TLS and default credential coverage across the internal estate, including the document management infrastructure.

  6. Stage 6

    External surface discovery

    Firms accumulate microsites for practice groups, events, publications and legacy branding. Reconnaissance enumerates what is reachable, which is usually more than the IT team expects.

    External Attack Surface Management
  7. Stage 7

    Fixes verified

    Retest re-runs the specific exploit and closes the finding only when the attack fails, with retest history attached, which is precisely what an outside counsel guideline asking for evidence of remediation wants to see.

04Features & Solutions

Relevant features and solutions

Multi-role and cross-matter access testing: the information barrier problem, tested rather than assumed.

Accounts on either side of a screen are held at once and each is pointed at the other's matter. A barrier that exists in the document management policy but not in the API behind it is only visible from that comparison.

Access control coverage: IDOR, horizontal and vertical privilege escalation, 35+ active tests.

Horizontal covers one user reaching a peer's records; vertical covers a junior role reaching a function reserved for a partner. Both are attempted against the roles you configure rather than inferred from the permission model.

Full authentication support: bearer, basic, cookie, custom headers, OAuth2/OIDC, scripted login with token extraction, sessions maintained and re-established.

Whatever the client portal authenticates with, the session is held for the length of the run, so testing does not stop at the login page of the systems that actually hold the work.

Session and JWT security: fixation with regeneration verification, timeout validation, algorithm_none, weak secrets, expired tokens, missing claims.

A token that outlives the matter it was issued for, or one whose claims a client can edit, hands over precisely what the engagement letter promised to protect.

Sensitive data and PII detection in responses, with verbose error monitoring.

Privileged material escapes by the incidental route far more often than the obvious one: a stack trace naming a client, an error message quoting the document it could not open.

Internal network assessment via Docker agent, outbound connectivity only.

The agent sits inside the network and reaches out, so nothing is opened inbound for it. Port, service and version detection, CVE matching, TLS posture and default credentials across the ranges you declare.

External surface discovery: subdomain and asset enumeration across practice group and legacy microsites.

Firms accumulate sites the way they accumulate matters: a merged practice, a conference, a rebrand two names ago. The forgotten ones stay routable long after anyone is responsible for them.

Application and API testing: REST, GraphQL and gRPC.

Imported from a spec where one exists, discovered from live traffic and client bundles where it does not, which is how the endpoints the portal itself never calls get tested.

API Security

Compliance evidence: control mapping for ISO 27001, SOC 2, GDPR, NIST, CIS and PCI DSS, with gap analysis, in five export formats.

PDF for the client security questionnaire, SARIF and JSON for the people fixing what it found, and the same underlying findings behind both answers.

05

Benefits

The obligation that defines the firm gets tested
Information barriers and client isolation, tested by attempting to cross them.
Client audits answered from generated evidence
Rather than from a scramble during a pitch.
A firm without a security team can still run one
Confirmed findings with remediation guidance are actionable by an IT team, which is who will actually be acting on them.
Security becomes a commercial asset
Firms that can evidence testing are increasingly at an advantage in panel appointments and instructions.
The internal estate gets assessed
Including the document management infrastructure that holds everything and is usually the least frequently tested system in the firm.
Remediation evidenced, not asserted
Retest history is what turns "we fixed it" into something a client's risk team accepts.
06

Use cases

Information barrier verification

Accounts across separate matters and teams, cross-access attempted across documents, matter records and search.

Client portal assessment

Multi-client testing with cross-client access attempted across shared portal infrastructure.

Outside counsel guideline response

A client requires evidence of testing. Run a Standard assessment, export the report with control mapping.

Panel appointment or pitch support

Producing current testing evidence as part of a competitive submission.

Document management system review

Internal assessment of the infrastructure and application layer of the firm's core system.

Data room pre-deployment check

Assessing a hosted data room configuration before confidential material is placed in it.

Post-merger integration

Assessing an acquired firm's systems before connecting them to the main estate.

Vulnerability Assessment

FAQs

Can you test our ethical walls?

Yes. By configuring accounts on separate matters and attempting cross-access between them. Information barrier failures are authorisation failures, and they only surface when a tool holds two identities at once and compares what each can reach. It is the most valuable test available to a law firm.

We do not have a security team. Can we still use this?

Yes, and the output is designed with that in mind. Findings arrive confirmed with the request, response and a reproducible curl command, plus remediation guidance including vulnerable and secure code examples. Your IT team receives specific changes rather than a report requiring interpretation.

Will this satisfy our clients' outside counsel guidelines?

It produces the technical testing evidence those guidelines typically ask for: testing methodology, findings with severity and control mapping, remediation guidance and retest history. Guidelines vary by client and some include requirements beyond technical testing, so the honest position is that this supports the response rather than completing it.

Can you test our document management system?

The infrastructure and any HTTP-exposed application layer, yes. Internal network assessment covers the hosts and services, and application testing covers what the system exposes over HTTP. Coverage of a specific vendor platform's internals depends on its architecture and is worth scoping directly.

How disruptive is testing?

Destructive actions are off by default, the request rate is configurable, and out-of-scope paths are respected. Firms typically test outside working hours for the core systems and any time for external surfaces.

Can we test a client's systems we host?

Only with that client's authorisation. Scope is verified before anything runs.

Prove the barriers hold

Test information barriers, client portals and the systems holding privileged material, and get evidence your clients' risk teams will accept.

Scope verified before any test runs · Destructive actions off by default

Security testing for other sectors

Same engine, different threat model, different auditor. Each page covers the systems, regulations and attack paths that sector actually lives with.

Financial Services

Payment flows, lending decisions, account servicing, open banking APIs — the logic that handles money is the logic attackers study hardest. It is also the logic no signature database describes.

Explore

Healthcare

Patient portals, scheduling systems, clinical APIs, payer integrations: all of it holds data that carries a lifetime of consequence if it leaks, and much of it runs on systems that cannot be taken offline for a test.

Explore

Government

Benefits portals, licensing systems, tax filing, records access — services that must be open to everyone by design, running on estates that were often built decades apart and connected later.

Explore

Manufacturing

Almost nobody breaks into a plant by attacking a controller. They arrive through a corporate account, a supplier portal, an ERP integration or an exposed remote access service, and then walk into a network that was designed for reliability, not for containment.

Explore

Retail

The vulnerabilities that cost retailers money are rarely exotic. A discount that stacks when it should not. A price accepted from the client. A gift card balance that survives a concurrent request. A loyalty account reachable from another customer's session.

Explore

SaaS

Every enterprise deal arrives with a questionnaire, a SOC 2 request and someone technical asking when you last tested. Meanwhile you ship on Tuesday and again on Thursday, and the last pentest describes a product that has since changed twice.

Explore

Telecom

A single authorisation flaw in a subscriber portal is not one exposed account. At operator scale it is a data set — and the same flaw in a provisioning API is an operational one.

Explore

Education

A department stood up a project site in 2019. A research group runs its own server. A faculty subdomain points at infrastructure that was decommissioned two years ago. None of it went through central IT, and all of it is reachable.

Explore