6

My startup is finally faced with the potential responsibility of handling PII, and we're concerned with doing it properly from a risk perspective but also so that we're doing this correctly.

What would be the best approach if we wanted to do it ourselves?

We don't currently have a security engineer, but we're operating relatively safely and in Google's Cloud Platform. We've made good design decisions in how our app security works, but we may have to start handling PII so we want to make sure that if it ever is at-rest we are covered.

I know Google offers certifications and white papers on their security, but I'm guessing we'd also need to get our own, from a third party auditor.

Any description of how to go about this would be immensely useful, from best practices and considerations to mandatory implementations.

4
  • 3
    You might want to identify what SORTS of PII, as different PII falls under different laws and regulations / practices and guidelines. Commented Sep 25, 2017 at 19:03
  • Ok sure - this would be non PCI-DSS data, so no financial/transactional stuff, just full names, emails, potentially locations, etc..
    – redband
    Commented Sep 25, 2017 at 20:03
  • GDPR is something you likely have to look at. Not only does it define what PII is, but it provides guidelines on how to handle the different types of PII. Is this the kind of thing you are looking for?
    – schroeder
    Commented Sep 25, 2017 at 21:59
  • I guess I should mention I'm also in the US - is the GDPR something specific to the UK or is that generally applicable?
    – redband
    Commented Sep 25, 2017 at 22:20

3 Answers 3

1

This is a very broad question, so I'm suggesting a broad answer. Check out the NIST Cybersecurity Framework, which is a comprehensive plan you can follow to help ensure you're covering all the bases.

0

So we want to make sure that if it ever is at-rest we are covered.

If you are storing the PII, you'd want to ensure that the data is encrypted when stored using strong cryptographic algorithms such as AES with as long as a encryption key as supported by the algorithm and your business needs. If you use encryption to store your data, it is critical you securely store the decryption / encryption keys securely. Ideally the decryption keys should be stored as separated from the data its protecting as possible. If your application is able to support using a Hardware Security Module (HSM) then by all means use one.

You asked for some best practices when securing data at rest. Some best practices when using encryption to protect data at-rest you may want to think about implementing:

  • Do not try to home-grow your own cryptographic encryption method
  • Always use strong encryption algorithms such as AES 256, or RSA
  • if necessary store passwords using in hashed format with a salt
  • Change encryption keys periodically

The above list is just a suggestion of some good practices and and is not meant to be exhaustive. Above all, if you do not need to store PII, then Do Not Store It.

-1

As @Robert Mennel specified in the comments, the answer to your question strongly depends on the type of Personally Identifiable Information you're handling.

To my knowledge, if you are handling:

  • Personal Health Information you are federally required to be HIPAA compliant.

  • Credit Card Information: you must be PCI DSS compliant.

  • General PII: look into ISO certification, or SOC1 compliance.

1
  • ISO and SOC1 are not going to be helpful with PII. GDPR is the kind of thing you would be looking for. The OP states no PCI data, and also states that the type of data is not medical. So, I'm not sure if this answer helps at all.
    – schroeder
    Commented Sep 25, 2017 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .