Does your software process data relating to customers, employees, patients or study participants? Then Article 25 of the GDPR requires data protection by design and by default – privacy by design, for short. Data protection that is only built in afterwards is expensive and often remains incomplete. We develop software so that the protection of personal data is part of it from the very first planning stage, and we review existing applications to find where it is missing.
Privacy by Design: What It Means in Practice
- Data minimisation: The software only records what is necessary for the purpose. Every field containing personal data must be justified.
- Authorisation concept: Each role only sees the data it needs for its task – in the user interface as well as in interfaces and exports.
- Encryption: in transit and at rest, where necessary also for individual fields, with keys that are stored separately from the data.
- Pseudonymisation: for example, measurement and sample data kept separate from the people they belong to.
- Deletion concept: Retention periods are stored in the software, and data is deleted on time and traceably.
- Data subject rights: Access, rectification and data export via a function in the software instead of manual work in the database.
- Logging: Traceable records of who changed which data and when – without the log itself becoming an unnecessary collection of data.
- Privacy-friendly default settings: Optional data collection and transfers are switched off initially, and retention periods are kept as short as possible.
Secure Software Development
Data protection depends on the security of the software. That is why the following points are part of our development process:
- Threat analysis during planning: Where could someone attack, and what would the damage be? From this we derive requirements before the first line of code is written.
- Secure programming: Input is validated, errors are handled properly, and permissions are granted as sparingly as possible.
- No secrets in the code: Passwords and keys are kept in protected configurations, not in the source code.
- Keeping an eye on dependencies: Third-party libraries are recorded and kept up to date – the basis for the software bill of materials under the Cyber Resilience Act.
- Tests without real data: We develop and test with fictitious or anonymised test data.
- Reviews with security in mind: Changes are reviewed by a second person, including for security and data protection. Find out more under Quality Audit and Code Review.
Reviewing Existing Software
For an existing application, we start with an inventory: which personal data does the software process, where is it stored, where does it flow to, and who can see it? The result is a list of measures, ranked by urgency and with estimated effort. The technical details support your data protection officer, for example with the record of processing activities or a data protection impact assessment.
If you wish, we implement the measures ourselves – for instance retrofitting an authorisation concept, encrypting sensitive fields, building in a deletion concept or adding an export function for subject access requests.
When We Work with Your Data
As a rule, we do not need real personal data for development and testing. Where it is necessary after all, for example in support when analysing a fault, we cover this with a data processing agreement under Article 28 of the GDPR and restrict access to what is necessary.
Please note: We carry out the technical implementation, not legal advice. We coordinate legal assessments with your data protection officer, your legal department or your lawyers.
You can find all our quality and security services in the overview.
Your Next Step
Whether new software or an existing application: in an initial consultation, we clarify which data your software processes and where action is most needed.
kununu