Checking supplier creditworthiness: legal basis, information and erasure period

A business that retrieves a supplier’s credit information from a commercial database needs a clear data protection basis. The first question is whether the record concerns an identified or identifiable natural person. The business must then define the purpose, source, information, accuracy, access and erasure period before the check.

A company credit record may initially concern a legal entity. Sole traders, personally liable individuals and management or contact details can create a link to a natural person. This article covers credit checks in B2B procurement. Customer credit, employee data, automated credit decisions and general access requests require separate assessments.

The GDPR protects information about an identified or identifiable natural person. A commercial database may assess the payment reliability of a company. If it also contains names, sole trader information, personally liable individuals or contact details, the personal data question must be assessed separately. The word “supplier” does not answer it.

The assessment depends on the record and the means used to identify someone. A code or a link to an existing supplier account may be enough if attribution is reasonably possible. The retrieval should therefore be documented with the fields that are actually used.

Article 5(1)(a) to (f) GDPR requires lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. Article 5(2) places responsibility for demonstrating compliance on the controller. A credit check starts with clarifying the data and purpose.

Article 6 GDPR permits processing only where at least one legal condition applies. A supplier credit check in B2B procurement will often require an assessment under Article 6(1)(f) GDPR, legitimate interests. The interest must be described specifically. General caution about every supplier is not enough.

The assessment asks three connected questions. What economic or organisational interest does the business pursue? Is the retrieval necessary for this procurement case? Do the interests or fundamental rights of the person nevertheless prevail? Record the answer before the first retrieval and include the data scope, source and intended access.

Other legal bases may apply depending on the facts. Article 6(1)(b) GDPR covers processing necessary for a contract with the data subject or for pre-contractual steps taken at the data subject’s request. With a supplier company and a linked natural person, this condition must not be assumed without examining the relationship.

The legal basis must also match the actual use. If the result is later used for a general supplier ranking or an automated refusal, that step needs its own assessment. This article covers a procurement credit check and not automated individual decision-making.

A business that obtains credit data from a commercial database usually collects it from a source other than the data subject. Article 14 GDPR then applies. The information must explain who controls the processing, for which purpose the data are used and which legal basis supports the retrieval.

Article 14(1) GDPR also covers the categories of personal data, recipients or recipient categories and intended transfers to third countries. Article 14(2) adds information required for fair and transparent processing. This includes the storage period or the criteria for setting it, the legitimate interests pursued under Article 6(1)(f) GDPR and the relevant data subject rights.

The source should be named specifically enough to be understandable. Saying only “public sources” does not show which commercial database supplied the record. The information should also explain which data categories are retrieved and whether the result is used only for the procurement review or for additional supplier processes.

Article 14(3) GDPR governs the timing of the information. The relevant point depends on when the data are obtained, when the first communication with the person takes place or when disclosure to another recipient is planned. Any Article 14(5) exception must be assessed and documented for the actual process.

Article 5(1)(d) GDPR requires accurate and, where necessary, up-to-date data. A credit record is therefore not a permanent finding. Record the retrieval date, source, relevant data category and internal use. The older the record, the more carefully its significance must be assessed.

An unusual or contradictory record requires clarification before an adverse procurement decision. The next step may be a query to the database provider, a review of current documents or a request for the supplier’s position. The process should identify who assesses an inaccuracy and how rectification or erasure is initiated.

Purpose limitation restricts later use. A retrieval for a specific order must not silently become a permanent supplier profile for unrelated purposes. Where results are stored in a procurement system, the access group, use and storage logic must fit that purpose.

The article on reviewing new software and AI before rollout addresses the preliminary risk question for new technologies. Its DPIA analysis does not replace the case-specific review of credit data. A single database retrieval also does not turn a manual procurement review into an AI application.

Article 5(1)(e) GDPR does not set one erasure period for every supplier credit check. Personal data may remain identifiable only for as long as necessary for the purpose. The business must therefore define the specific review purpose and when it ends.

For a single order, the purpose may end with the procurement decision. An ongoing supplier relationship may justify recurring checks. Even then, the business needs a verifiable criterion connected to the procurement or risk process. Permanent storage out of habit is not a sufficient explanation.

The erasure review must cover the result and notes derived from it. Check database extracts, email attachments, local files, tickets and copies in procurement systems as well. Erasing the original retrieval while keeping a personal assessment can leave the personal data link in place.

Article 14(2)(a) GDPR requires the storage period or the criteria used to set it to be communicated. The information should match the internal erasure concept. If another legal duty or a specific need to establish or defend claims points to longer storage, that additional basis and scope require a separate assessment.

Access to the credit result belongs with the people handling the specific procurement or approval process. Article 5(1)(c) and (f) GDPR support limited, purpose-related use and appropriate security. A storage location accessible throughout the business is difficult to reconcile with that purpose.

Define which roles may view the raw record, who receives only an approval recommendation and who may investigate an inaccuracy. Log retrieval, changes and erasure so that later control remains possible. Review permissions when a person changes roles and when the review purpose ends.

A manual credit check must be distinguished from an automated decision. If software decides about a supplier or natural person without meaningful human review, additional questions arise. The existing article on automated credit assessment addresses that separate situation. It does not replace the controls for a manual procurement check described here.

Before the first retrieval, prepare a short approval record. It should state the procurement process, specific purpose, possible personal data link, selected fields and source. A setting in the procurement system alone does not show this decision sufficiently.

Add the legal basis and, for legitimate interests, the balancing assessment. Explain why the retrieval is necessary for the specific procurement case, which roles receive access and how contradictory or outdated records are handled.

Prepare the Article 14 GDPR information. It should explain the source, categories, purpose, legal basis, recipients, storage period or criteria and rights in clear language. Check the timing of the notice and any exception before starting the process.

Finally, define the erasure event, criterion and responsibility. After the review, assess the result, document the procurement decision as required and remove the credit data and known copies when the purpose ends.

The personal data link is dismissed: The record concerns a supplier but contains information about a natural person or identifies someone through the supplier account.

The legal basis is a formula: “Risk review” does not explain the specific interest, necessity or balancing assessment.

The source is left unnamed: The data subject cannot understand which commercial database supplied the information.

An old record is treated as current: Retrieval date, accuracy, contradictory information and the correction route are ignored.

The result remains in the procurement system: The erasure period covers the database retrieval but not the notes, extracts and attachments derived from it.

Every procurement role receives the same access: Raw data and credit assessments are shared without a task-related limit.

We assess the link to personal data, the procurement purpose, legal basis, business-information database, Article 14 GDPR information, authorised roles and erasure controls together. For a first assessment, useful material includes the process description, a sample database extract, the legitimate-interest assessment and the proposed erasure concept. This keeps the credit check traceable within procurement.

For the distinction between personal-data status and additional knowledge, the article on anonymisation and pseudonymisation provides further context. If a data subject then approaches your business, the article on Article 15 GDPR access requests explains the general handling sequence.