7
10 Comments

GDPR compliance for a small SAAS whose only personal data is email and password

Hi indie hackers,

I'm not finding anything that says exactly how small SAAS needs to comply with GDPR when the only personal data we store is sign up data (email, password), and the only way we use it is for contacting our customers.

Do we still need to document how we "process" this data? or just been explicit about the kinds of emails we'll send to our users should suffice?

Maybe someone here can point me in the right direction, all info I find seems more like for bigger companies that store more personal data and process it in different ways.

Thanks in advance.

  1. 5

    Hey @messutied, I just posted in this other thread, but here are some things to think about:

    • Email and IP addresses are personal data (art. 1).
    • If you're reading through the GDPR, be mindful of the word "controller", because your website/service is a controller (art. 7).
    • An email address used for signup/login is a legitimate interest.
    • Someone signing up for your service doesn't imply consent for marketing/promotional email. You'll need an explicit opt-in for this with very clear wording. (art. 2, 3, 4)
    • Users that are opted in for marketing email need an easy way to opt out again (e.g. on their dashboards/control panel).
    • Communication solely about (and required for) your service (e.g. invoices) does not need an opt-in.
    • You need to maintain records of processing activities. You can list this in your Privacy Policy.
    • You need to comply with all of the rights of the data subject at all times. Use this as a checklist before publishing anything publicly.

    You don't always need explicit consent for processing personal data (I'm mostly referring to IP addresses), but you do need very clear and easily available communication.

    I hope this helps. If you have more questions, don't hesitate to send me an email. I'm making GDPR Wall, so I'd like to hear more about your thoughts/concerns.

  2. 2
    1. You should be able to anonymous the customer data when they wanted to remove their account from your platform.

    2. The platform should also provide some mechanism to clean up / remove the user related information (some kind of utility).

    3. The passwords which you stored in your platform should be encrypted. These are some of the basics...

    1. 1

      If the customer wants you to remove their data, you have to remove their data. Anonymisation is never truly anonymous (not if you intend the data to still be useful).

  3. 2

    I was curious about this as well. Are we allowed to deny access to people in the EU until our services become compliant? The territorial scope of GDPR seems a little ridiculous: https://gdpr-info.eu/art-3-gdpr/. How can this be enforced on businesses outside the EU?

    1. 1

      You can deny access to anyone you like. An EU citizen connecting through a VPN outside of the EU is still covered by the GDPR though, so your liability, although reduced, still exists.

    2. 1

      @Matt1

      How can this be enforced on businesses outside the EU?

      It's because the GDPR defines the rights of the visitor, not the host. Luckily, a person doesn't lose his/her rights just because they're browsing something not in the EU. But it does cause some difficulties.

      Are we allowed to deny access to people in the EU until our services become compliant?

      This is a good question. I'm not a lawyer, so I can only recommend asking a local lawyer since it will depend on your local law.

      There are alternatives to blocking them entirely though. Would you be up for a quick chat (email or Telegram)? I'm building something related and I'd like to hear your thoughts.

    1. 1

      Wow this article is the best for me so far, very clear and all applies to my case, thanks a lot, also the link they point to at the end (https://techblog.bozho.net/gdpr-practical-guide-developers/) looks great, thanks a lot!

  4. 1

    Lots of the information you need has already been listed here. But there's one thing I'd like to add which is likely relevant.

    Whenever in scope data is processed outside of the EU, it's considered an International Transfer and the appropriate safeguards must be in place. More info from the UK's Supervisory Authority here: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/international-transfers/

    For companies in the USA, you can use the EU-US Privacy Shield to demonstrate compliance with data protection principles. More information here: https://www.privacyshield.gov/welcome

    Here's an example of it in use: https://www.sageintacct.com/privacy_policy_website

  5. 1

    Size of your business is not the criteria for the GDPR - if you're processing personal data, you should comply. However, some requirements are related to larger enterprises, e.g., records of processing activities: if you're small, you don't need to maintain these records. Note that you're obligated to do so if your processing is not occasional. For the details, see https://gdpr-info.eu/art-30-gdpr/

    My opinion is that processing records should be the first thing you should do when you start to think about the GDPR. List all activities you perform in your company related to personal data - that's the basis for records of processing activities. Add additional information to them, and it should be a good start. You can find Excel file with samples here: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/documentation/

    Once you recognised business processes dealing with personal data, the next thing on your to-do list is to determine what's the lawful basis for each processing. After that, start collecting consents (if you have processing activities that require consent) and keep an eye on data subject rights. It's a chance that you'll have to deal with the right to object - a most common example is email unsubscribe.

    Keep an eye on our blog for more details: https://www.gdprhq.io/post/gdpr-hq-its-time-to-dig-in