Wall & Fifth
Skip to content

Wall & FifthData Protection

Their information.
Your responsibility.

Understand what your product collects, where it goes and who can access it. Make those decisions before the data starts arriving.

Designed with purpose. Built with care.Security is part of the product.

The principle

Start with a clear picture of the data.

Personal information can move through more places than the main database: email, analytics, support tools, payment services, backups and logs. A useful plan accounts for the whole journey.

Data protection involves the full life of information: collection, use, access, storage and deletion. Technical safeguards support those decisions, while the business remains responsible for defining its purposes and obligations.

Collection & purpose

Only collect what the product needs.

Every additional field creates something else to protect and maintain. During product planning, identify what each piece of information is used for, which features depend on it and whether the same task could work with less data.

Sensitive information changes the requirements. Health details, identity documents and information about children should be raised early so the architecture, access model and specialist advice can be scoped appropriately. A general-purpose contact form should not quietly become a repository for sensitive documents.

Access & storage

Know where information lives.

The project needs decisions about database access, file storage, administrative permissions and the services that receive customer information. Public and private files need different access rules. A hard-to-guess URL is not, on its own, a reliable permission system.

Encryption in transit protects information travelling between systems. Encryption at rest concerns stored information. Both need to be assessed against the services and configuration actually used, alongside key management and the accounts able to read the data.

Hosting location and third-party processing should be checked against the requirements of the business and its customers. The location of one database does not establish where every analytics event, email or backup is processed.

The data map
Record the systems that store or receive information, including integrations and logs.
The access model
Identify who can view, export, change and delete information in each system.
The configuration
Confirm the provider, region and security settings required for the project.

Retention & deletion

Plan the end of the data’s life.

Information should not be kept indefinitely simply because storage is available. The product brief needs a decision about retention periods, account closure, exports and deletion. The technical implementation then needs to reflect that decision.

Deletion can involve more than removing a row from a database. Files, external services and backups may follow different retention rules. Those limits should be understood so the product and its communications describe the behaviour accurately.

Read about maintenance and recovery

Business & technical roles

Turn requirements into product behaviour.

Your business defines why information is collected and how it should be used. The development brief translates that into features and controls: permissions, notices, retention settings, exports and deletion workflows where required.

Legal obligations, controller and processor roles, supplier agreements and any need for an impact assessment should be resolved with appropriate advice. A well-built application supports compliance work; it does not make a business automatically compliant. The ICO’s data-security guidance is a useful starting point for the security aspect.

Clarity from the start

The right protection.
The right agreement.

Your product’s risks, controls and support needs belong in the project conversation. We’ll help you define the brief and identify what needs a separate assessment or specialist input.

Talk through your requirements

Straight answers

Before you
put your trust in it.

Will my application be GDPR compliant?

Compliance depends on your organisation’s purposes, policies, contracts and operation as well as the software. We can discuss the technical requirements the product needs to support. Legal assessments and compliance assurances need their own appropriate review.

Can data be hosted in the UK or Europe?

Location requirements should be specified before services are selected. Availability varies by provider and plan. Check the complete data flow, including backups, email, analytics and other processors, rather than only the primary database.

Can users export or delete their information?

These workflows can be included in the scope. Define which information is covered, how the user is verified, what must be retained and how connected services and backups are handled.

Will customer information be sent to AI providers?

Only the agreed architecture and configuration can answer that. For an AI feature, identify what leaves the application, which provider receives it, the relevant retention settings and whether sensitive information can be excluded or reduced before transmission.

Keep exploring

The rest of the picture.

Back to Security & Support