Is It Lawful to Reverse Engineer a System From Recordings and Screenshots?

Two questions that get confused with each other

Teams asking whether they can record a legacy system and analyse it usually have one question in mind. There are two, and conflating them is what produces both unnecessary caution and unnecessary risk.

Question one is about the system. May you examine it, record it, and derive a specification from it? This turns on who owns the software and what any licence says.

Question two is about the recording. Once you have footage of a working business system, what does data protection law require of you? This turns on what is visible on screen, and it applies regardless of the answer to question one.

Most organisations worry about the first and overlook the second. In practice, for a system the organisation owns, the first is usually straightforward and the second is where the real obligations sit.

Does it matter who owns the system? Yes, more than anything else

The single most important fact is whose expression you are looking at. The table below sets out the three positions we see most often.

The distinction is not a technicality. It changes what the exercise is. Recovering the requirements of a system you own is documenting your own asset. Reproducing a vendor’s interface is copying somebody else’s work, and no amount of tooling changes that.

Two points of caution on ownership, because it is asserted more often than it is verified.

Commissioning is not the same as owning. Under English law, copyright in commissioned software vests in the developer by default unless the contract assigns it. A great many organisations believe they own systems they paid for and in fact hold only a licence. Check the original development agreement before assuming.

Source code escrow is not an assignment. Escrow gives you access in defined circumstances. It does not, on its own, give you the right to create derivative works.

What does UK law actually permit?

For the situations covered by this guide, the statutory reverse engineering provisions are less relevant than teams expect.

Section 50B of the Copyright, Designs and Patents Act 1988 permits decompilation of a program where necessary to achieve interoperability with an independently created program. Section 296A can void contractual terms that purport to prohibit certain permitted acts. These matter, but note two limits. They concern decompilation of code, and they are directed at interoperability, not at replicating a product’s functionality.

Observing a system you own does not usually engage these provisions at all, because you are not relying on a statutory exception to somebody else’s rights. You are exercising your own.

Where they do matter is the third row of the table above, and there the analysis is genuinely difficult and specific to the wording of your agreement. That is a question for a solicitor qualified in intellectual property law, not for a general guide.

There is also a well-established principle that functionality itself is not protected by copyright, only the expression of it. This is why a clean-room approach can work at all. It is not a licence to copy the interface, and it is a weaker protection than it is often assumed to be once AI tools enter the process, for the reason set out next.

Why feeding a vendor’s screens into an AI tool is a problem

Our guide on the legal position when replacing SaaS with a custom build sets out why screenshot-to-code from a vendor’s product is a practice to prohibit outright. That guidance is unchanged, and this guide does not soften it.

The reasoning is worth restating, because it explains exactly where the boundary sits. A clean-room approach depends on separating the team that observes what software does from the team that builds the replacement. The observers write a functional description in their own words. The builders work only from that description, never from the original.

When you paste a vendor’s screen into a model and ask it to produce an interface, you have handed the build side a copy of the protected expression. The output is shaped by specific layout compositions, colour choices, iconography, and typography that may attract copyright or design right protection. That the generated code is new does not help if the rendered result reproduces protectable design elements.

None of that applies when the screens are your own organisation’s. There is no clean-room boundary to maintain, because there is no third party’s expression in the room.

The practical rule: the question to ask before any screen goes into an AI tool is not “is this a screenshot” but “whose expression is this, and do we hold rights in it”.

What about the personal data in the recording?

This is the obligation that applies in every scenario, including the ones where ownership is not in doubt, and it is the one most often missed.

A walkthrough of a real business system shows real records. A customer relationship management system shows named individuals and their contact details. A case management system shows case detail that may reveal health, criminal justice, or other special category data. A booking or membership platform shows names, addresses, and payment information. The moment you record that, you are processing personal data, and everything that follows is subject to UK GDPR and the Data Protection Act 2018.

Our guide to data protection by design in software makes the point that live personal data has no business sitting in a developer’s test database or in a screenshot attached to a ticket. A recording of a production system is the same problem at greater volume.

Minimise first, because it is far cheaper than justifying afterwards

In order of preference:

• Use a training or demonstration environment populated with synthetic data. This removes the issue at source and is almost always possible for the workflows that matter.
• Use anonymised or masked data in a copy of the production environment.
• Use production with deliberate restraint. Select records that minimise exposure, avoid special category data entirely, and pause recording for anything that cannot be avoided.
• Redact afterwards. Workable, but the most expensive option and the easiest to do incompletely.

The first option is worth pushing for even when it takes a week to arrange. It converts a legal problem into a scheduling problem.

Crop before you index

There is one further control that costs almost nothing and is easy to overlook. A meeting recording contains far more than the system being demonstrated: participant video tiles, browser chrome, bookmarks, notifications, and whatever else is on the presenter’s desktop.

Crop each frame to the application alone, as a batch step before anything is indexed or analysed. That removes participants’ faces from the dataset entirely, and eliminates a category of incidental disclosure nobody intended to capture. Because it happens at the start of the pipeline, the personal data never reaches the indexing, the AI processing, or the stored artefacts. There is then nothing to justify retaining later.

This is worth writing into the method rather than leaving to whoever is preparing the files. It is described as a processing step in the companion guide on the method itself, and it is equally a privacy control.

Get the lawful basis right

For the customer or client personal data visible on screen, legitimate interests is usually the appropriate basis. Support it with a documented legitimate interests assessment covering the purpose, the necessity, and the balance against the rights of the individuals concerned. Consent is generally not workable, since you cannot practically ask every customer whose record appears.

For the staff taking part in the workshop, the same reasoning applies. Consent is a weak basis in an employment context because of the imbalance of power. Legitimate interests, with clear notice, is normally sounder.

Whatever the basis, tell participants what is being recorded, why, who will have access, and how long it will be kept. That is a transparency requirement, and it also produces better sessions. People narrate more openly when they know what is happening to the recording.

Decide what may go into the AI tool, and record the decision

Sending a recording to an AI service is processing by a third party. Before it happens, establish:

• Which specific service is being used, and under which terms.
• Whether inputs are used to train models, and whether that can be disabled.
• Where the data is processed, and whether any international transfer is adequately covered.
• Who has access to the outputs, and where the artefacts are stored.
• How long the provider retains the input.

Where the processing is likely to result in high risk, a data protection impact assessment is required rather than advisable. Recordings of a production system containing special category data will often meet that threshold. If your organisation holds ISO 27001 certification, this decision should also be traceable through your existing supplier assessment process.

Set retention before you record

Raw recordings have a short useful life. Once the analysis has produced the verified artefacts, the footage rarely needs to be kept. Decide the retention period in advance, apply it, and delete on schedule.

A checklist before the first session

1. Confirm ownership in writing. Find the development agreement or the licence. Do not rely on the assumption that paying for something means owning it.
2. If it is a third-party product, stop and take advice. Review the terms for reverse engineering and non-replication clauses, and read the SaaS replacement legal guide before recording anything.
3. Choose the environment. Push hard for training or masked data. Record the reasoning if you end up in production.
4. Document the lawful basis, with a legitimate interests assessment where that is the basis relied on.
5. Screen for special category data specifically, and plan how to avoid it rather than how to redact it.
6. Assess whether a data protection impact assessment is required, and complete it before recording rather than alongside.
7. Approve the AI service against your supplier assessment process, covering training use, processing location, and retention.
8. Brief participants on what is recorded, why, who sees it, and for how long.
9. Set the retention period and the storage location, with access limited to the analysis team.
10. Delete on schedule, and record that you did.

Where this leaves you

For a system your organisation owns, the honest summary is that this is a routine exercise with a routine data protection wrapper around it. The legal work is real but bounded, and most of it is done once and reused across the estate.

For a third-party product, the position is materially harder, the clean-room constraints in the SaaS replacement guide apply in full, and the exercise should not begin without specific legal advice.

The method itself is covered in reverse engineering a legacy system that has no documentation, which sets out how the workshops run and what the analysis produces.

This guide provides general information about UK copyright and data protection law as it applies to examining and recording software systems. It is not legal advice, and it reflects the position as at August 2026. Consult a solicitor qualified in the relevant field, and your data protection officer where you have one, for advice specific to your circumstances.