Handling supplier contact data when you automate certificate chasing

A supplier contact's name and work email address are personal data under the GDPR. The regulation protects identifiable individuals, and an address in the form of a first name and surname at an ingredient supplier identifies one person, so it sits in scope in the same way a home address would, even though the only use you ever make of it is asking for an allergen declaration. Automating the chase does not change the legal position. It changes the volume and the cadence: a spreadsheet you email from twice a year becomes a system that holds those contacts continuously and writes to them on a schedule you set once.

Two things follow for a food plant. First, you are the controller of that data, because you decided to collect it and you decide what it is used for. Software that holds it for you is a processor acting on your instructions, and that relationship needs to be written down rather than assumed. Second, your certificate library is not only a set of business documents. Certificates of analysis, third-party audit certificates and allergen declarations routinely carry named signatories, technical managers and auditor names, so you also hold personal data about people you never contacted, inside documents you did not draft and cannot correct.

None of this is an argument for chasing by hand. Manual chasing scores worse on nearly every measure that matters here. Contacts live in individual inboxes, old addresses are never cleaned up, nobody can reconstruct who was emailed and when, and there is no single place to go when somebody asks to be removed. The useful goal is not less automation, it is automation set up so that the data side is tidy from the first supplier you add. What follows is a working summary written for QA managers, not legal advice; your adviser or data protection officer has the final word on the basis you choose and the wording you publish.

Every use of supplier contact data needs a lawful basis under Article 6. For certificate chasing, legitimate interests under Article 6(1)(f) is normally the honest answer. The test has three parts: the interest has to be real, the processing has to be necessary for it, and you have to weigh it against the individual's rights and record that you did the weighing. A QA team can state the interest in one sentence. You cannot run an approved supplier programme without current certificates, and you cannot obtain current certificates without a named contact to ask. Write that down as a short legitimate interests assessment, date it, and file it with your document control records, because "we have always had their email" is not an answer to an auditor or to the person asking.

Consent is a poor fit. Consent has to be freely given and capable of being withdrawn, and if a supplier contact withdrew it you would still need the certificate, so you would be leaning on a basis you cannot actually honour. Some plants prefer to rely on performance of a contract where the technical contact is named in the supply agreement. Either route can be defensible. What matters is that you pick one, record it, and tell people: Articles 13 and 14 expect a supplier contact to be able to find out that you hold their details, why, and for how long. In practice that is one line in the supplier onboarding pack and one line at the foot of the chase email, not a notice nobody reads.

Keep one boundary clean. A reminder that a certificate of analysis expires in sixty days is a transactional message inside an existing commercial relationship. A newsletter, a product announcement or an event invitation to the same address is marketing, and marketing sits under separate electronic communications rules in most jurisdictions. Keep the chase list and any marketing list apart, and do not let one quietly become the source for the other. The practical test is whether the message would still be sent if you had no commercial interest in the recipient hearing from you.

Data minimisation is the requirement that pays for itself fastest in a QA context. The smaller the contact record, the less there is to keep accurate, the less to explain, and the less to delete when somebody asks. It also happens to make chasing work better, because a short record is one a QA assistant can maintain in the ten minutes a week they actually have.

The single highest-value change is to ask each supplier for a role address rather than an individual's mailbox. Quality at a supplier, or technical documents at a supplier, is still personal data in the sense that a person reads it, but it is not tied to one named employee, it survives their departure, and it removes the most common cause of a chase arriving nowhere, which is a bounced address nobody noticed. Certly's supplier record holds the supplier company name, a contact name and a contact email address, and the form validates that the email is a real address and that the required certificate types and expiry date are present, so a role address passes exactly as an individual's does.

Two habits do the rest. Keep the required certificate types as types, so the record describes an allergen declaration or an audit certificate rather than carrying free-text notes about who at the supplier is difficult to reach. And resist the field creep that spreadsheets invite: direct dial numbers, personal mobiles, job history, informal comments. None of it makes a certificate arrive sooner, and all of it is data you would have to surface if the person ever asked what you hold on them.

Minimisation and retention pull in opposite directions here, and the resolution is not the same for every record. An expired certificate is not clutter, it is the evidence that the supplier was approved during the period you were buying from them, and the chase history is the evidence that you acted when a document lapsed. A storage limitation policy that quietly deletes both after twelve months will leave you arguing an approved supplier programme from memory.

So split the record. The certificate documents and their issue and expiry dates, and the log of what was sent and whether it was delivered, are the trail an auditor asks for, and they justify a retention period measured against your certification cycle rather than against the shortest period you can defend. The contact's name and email address are different: they exist only to make the next chase land, so they have no reason to outlive the relationship. Write both decisions into your document control with a review date, and name who checks them.

Certly's declared handling follows that logic. Everything is kept while your account is open, expired certificates and chase history included, because that is what an auditor asks for. Archiving a supplier you no longer buy from keeps its documents and chase history on file and stops its reminders. Deleting your account from Settings removes the suppliers, certificate documents, chase history, settings and sign-in details at once. Supplier upload links expire on their own, and a spent link holds no document, so an old email in a supplier's inbox is not a standing door into your certificate store.

Access first, because it is the control an auditor and a supplier both ask about. Give accounts only to the QA people who need the supplier list, and take them away on a role change or a leaver, on the same day you do it for the site's other systems. Certly's accounts are email and password today, with no single sign-on and no two-factor option, which means your password practice and your leaver process are doing that work rather than an identity provider. Sign-in session records, including IP address and browser, are kept so sessions can be kept secure, and every supplier and certificate query is scoped to your plant, which the sibling page on plant-level data isolation covers in detail.

The erasure request you receive is rarely "delete everything about this supplier". It is almost always one person saying, in effect, take my name and my email off your system, usually because they have changed roles. That request and your audit trail are compatible, because the certificate is a business record about a company and the contact details are not part of it. Certly handles it as one action on the supplier's page: a delete contact data step behind a confirmation dialog that states what will be removed, the contact name and email, and what will remain, the certificate records, backed by a right-to-erasure endpoint for supplier contact personal data. The declared handling adds that any unused upload links sent to that contact stop working at the same moment, which is the part a paper-only process usually forgets.

One case stays genuinely hard: the names printed inside the certificate your supplier issued. You cannot redact a PDF that is itself the evidence without damaging the evidence, and you are not the author. The workable answer is to treat the request as one for the issuing company, ask the supplier to reissue the document where that is possible, record what you decided and why, and be able to show the request and the response. Writing that position down once, before anyone asks, is cheaper than improvising it under a deadline.

Once you put supplier contacts and certificates into software, your processor's answers become part of your own compliance position. Ask these before the trial, not after, and get them in writing.

• Where is the data hosted, and can you choose the region
• Is the uploaded document stored separately from the database, and who can reach it
• Who are the subprocessors, and what does each one do
• Is there a data processing agreement ready to countersign
• How do people sign in, and is single sign-on or two-factor available
• Is there an independent security certification
• How is one customer's data separated from another's
• What exactly happens on an erasure request, and on account deletion
• What can you export if you leave

Certly's answers today, from its own declarations: hosted on Amazon Web Services, in the product's own Postgres database, with uploaded certificate documents in that same database rather than a shared file store. Subprocessors are Amazon Web Services for hosting, Stripe for card payments and subscriptions, and Resend to deliver chase and upload-link emails and report delivery and opens back. Sign-in is email and password. Supplier and certificate queries are scoped to a single plant, one tenant per plant.

And the honest list of what is not in place: no independent security audit or certification such as SOC 2 or ISO 27001, no single sign-on or two-factor authentication, no standard data processing agreement ready to countersign, no published backup and disaster-recovery schedule, no choice of data residency region, and no self-serve export of the full data set, since the PDF export covers the dashboard rather than every stored record. If your plant is in the EU and your policy requires a signed processing agreement and a named region before any supplier personal data moves, that is a reason to talk to us about timing rather than to start uploading. We would rather you read that here than discover it in a procurement questionnaire.

The data protection part of a supplier approval review is usually short, and it goes well when four documents exist. A one-paragraph note of the lawful basis you rely on for holding supplier contacts, dated. A transparency line you can point to in the onboarding pack and in the chase email. A retention position that separates certificate records and chase logs, which you keep, from contact details, which you do not keep longer than the relationship. And a named route for an erasure request, with an example of one you handled.

Notice what none of that requires: a consent campaign, a new policy framework, or a project. It requires decisions you can make in an afternoon and then follow. Automation helps because it makes the decisions visible in one place, a single contact per supplier, one record of what was sent and whether it arrived, one action that removes a contact's details and leaves the certificate record standing, rather than scattered across inboxes where nobody can prove any of it.

What automation does not do is take over the judgement. A tracking system tells you a document is approaching its expiry date and reminds the right person; deciding whether the document is genuine, whether the supplier is still approved, and whether the certificate covers the sites and scopes you buy from, stays with the QA team. The sibling page on what Certly does and does not claim to do sets out that boundary, and it is worth reading before you write the tool into a procedure.