[idrios]

I think "reasonable measures" is pretty typical language when talking about compliance. I don't know GDPR regulation very well but I know FDA regulation reasonably well and I imagine compliance will be similar, and much easier for the new GDPR.

Most important is to document everything. Have a design history file that you can show in case you get audited. When you design your software, save your designs in the DHF. When you update or make changes to the design, put that in your DHF too.

For each GDPR article where it makes sense, have it written somewhere how you are compliant with what they ask for (you probably don't need to demonstrate compliance with Article 4 [1] but you should have it written somewhere how you are compliant with all the points in Article 5 [2]. When it says "Personal data shall be: (b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes" You should be able to procure a document that lists the various kinds of personal data collected and how each is used; e.g. "Username: The username serves to associate a person's login id to their profile. [... other details] Profile Picture: The profile picture serves to display an image of the user. [... other details]."

When it tells you to have reasonable security measures, then document what your security measures are. "This data is encrypted" or "This data is saved on an external server disconnected from the internet and only accessible by someone with a dongle". If you're still worried that your user data could be insecure, then it might be worth hiring a security specialist to check it out.

[1] https://gdpr-info.eu/art-4-gdpr/ [2] https://gdpr-info.eu/art-5-gdpr/

[Kalium]

Well said! Thank you for your comments.

With all that said, my point was that it's not obvious what is and isn't reasonable. Hiring a security specialist won't necessarily help you understand what bureaucrats will or won't deem reasonable, especially when there's no history to provide context.

[idrios]

You're right about that. I guess for a rule of thumb, imagine what the reaction on HN will be if your system gets hacked, and assume bureaucrats will say the same thing. Will they be criticizing "Everyones' credit card information was saved in plain text" or will it be "Even though this disgruntled employee uploaded everyone's usernames to [untrustworthysite], most of that information is still encrypted and the company made a public announcement about it hours later".

It's your best guess what is and isn't reasonable. As long as you've documented what you did and why you did it, then you've satisfied that requirement. If an auditor finds what you've done to be insufficient, you'll probably get a warning but you'll still be considered compliant for having done something.

I know it's not a satisfying answer and I'm sorry that I don't have a better one, but complying with regulation is not as definite a "yes/no" as programming.

My knowledge is with the FDA so I'll give an example I'm familiar with. I worked with CT scanners and we needed to do verification/validation. The FDA requirement was to the effect of "must define reasonable requirements for the device" and "must set up testing procedures that reasonably demonstrate that a device can meet its requirements" and so the team I worked with set requirements like "radiation dose: <20rad when run on [x] setting" and then tested it at [x] setting 5-20 times, then documented "passes radiation dose test with 99% certainty, which exceeds our cutoff for passing which is 95%".

CT is an old industry so there was a bit more to it than that, but we were still following requirements that we had written, and testing them in with procedures we had made. The point is the requirements even in the health industry can be vague, so you really just have to do your best to come up with something reasonable.

And because it's vague, that's also why it's so important to document everything.