Data protection compliance in a new software project — where to start?

I agree with Tuba's framework, I'd like to add two points from an implementation perspective.

First, do not use real data in test environments. Copying production data during software development is very common and creates a copy not visible in your inventory. Add a clause to the requirements stating "masked data is used in test environments."

Second, access logs. Keeping records of who accessed which record and when is necessary for both compliance and incident investigation. This is a feature that is hard to add to the software later; request it from the start.

I'll write down the technical implementations from a developer's perspective, you can put them as items in the requirements.

Encrypted data transfer (i.e., HTTPS across the entire site) and encryption of sensitive fields at rest. Passwords should never be stored in a reversible way, they must be kept using hashing functions.

Role-based access: not every user should see every record. In small teams, people say "we all see everything anyway," then the team grows and no one goes back to clean it up.

Deletion must actually delete. In many systems, a deleted record is just hidden. If that's the requirement, fine, but it should be a conscious choice.

And access logs must be immutable by the user. If there's an admin account that can delete its own tracks, those logs have no evidentiary value.

Thank you so much, I forwarded these points directly to the developer.

We started rolling out the inventory part this week too, already found two unnecessary form fields.

Theres a trap here let me mention it. Forgotten test environments are more often the entry point than live systems.

Correct me if I'm wrong.

thanks that was the answer I was looking for then hasty decisions become decisions you have to fix six months later.

solutons that work at a small scale collapse when you grow; I learned this late. if you have questions, write them; I'll answer as best I can.

Let me clarify the technical side... I mean everything goes well for the first three months; problems arise in the fourth.

Start with a small trial; don't commit to everything at once. Of course it varies if your situation is different.

Saved.

I went through the same thing two years ago. The biggest time-waster for us was not knowing who had the final say.

This is my opinion, I'm not claiming it's absolute truth.

I'll try it.

Noted, thanks.

could you elaborate on that? having backups accessible on the same network and with the same identity makes them part of the target.

just because everyone does it doesnt mean its right. thats all sorry if I went on too long.

This thread is archived. Everything goes well for the first three months; problems arise in the fourth.

Proven by experience.

The opposite happened to me, that's why I'm writing. Don't rely on a single measure; go layer by layer.

Solutions that work at a small scale collapse when you grow; I learned this late. If I were you, I'd go this route.

This is exactly what we experienced. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.

This is my opinion, I'm not claiming it's absolute truth.

This approach has a cost, which isn't discussed. Your time to detect an issue directly determines its cost.

Your time to detect an issue directly determines its cost. Good luck with that.

Noted thanks. Just because everyone does it doesnt mean its right.

Just leaving this note, it might be useful.

I'm curious too.

Let me speak from the other side; I'm on the supplier side. Payment information changes are never verified through the channel they came from.