[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"article:en:the-gdpr-record-of-processing-for-a-software-company-the-seven-fields-of-article-30-1-the-four-of-article-30-2-why-the-250-person-exemption-never-applies-and-a-page-that-writes-it":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"answer":9,"body":13},"en","the-gdpr-record-of-processing-for-a-software-company-the-seven-fields-of-article-30-1-the-four-of-article-30-2-why-the-250-person-exemption-never-applies-and-a-page-that-writes-it","The GDPR record of processing for a software company: the seven fields of Article 30(1), the four of Article 30(2), why the 250-person exemption never applies, and a page that writes it","Article 30 is the one GDPR duty every other duty refers back to, and the one most software companies believe the 250-person exemption spares them. It does not: Article 30(5) lifts the exemption for any processing that is not occasional, and a product in use processes every day. The seven fields of a controller's record and the four of a processor's, read from the Official Journal, what each one is for, the ISO 27701 control that evidences it, and the free page that writes the record one activity at a time.","2026-09-12",{"who":10,"when":11,"do":12},"Every software company with a live product: as the controller of its own customer, prospect and staff data (Article 30(1)), and, where it processes data for its customers inside the product, as their processor too (Article 30(2)); at any headcount, because the processing is not occasional.","The record is due from the first processing and is produced to the supervisory authority on request (Article 30(4)); it changes whenever a purpose, a recipient, a transfer or a retention period changes, and its transfers field is where the Chapter V ground for every sub-processor outside the EEA is written down.","Write one record per processing activity with the free page, seven fields for the controller's side and four for the processor's, each labelled with the point of Article 30 it answers, and keep it where the processor contracts and the breach clock are.","\nAsk a software company for its GDPR paperwork and the first answer is usually a privacy policy and a processor agreement a customer sent. The document the Regulation actually names first, and the one a supervisory authority asks for first, is neither: it is the record of processing activities of Article 30, and the belief that companies under 250 persons do not need one is the most expensive misreading in the text. This article reads Article 30 point by point, says what each field is for, and hands you the [page that writes the record](\u002Fgdpr\u002Frecord-of-processing).\n\n## Why the 250-person exemption never reaches a product in use\n\nArticle 30(5) says the obligations of paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons. The sentence continues: unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10. Three conditions, any one of which restores the duty.\n\nThe second one decides the matter for software. A product in use processes personal data every day the service runs: logins, accounts, support tickets, telemetry, the customers' end-user data inside the product. None of that is occasional. The exemption was written for the bakery that keeps a Christmas mailing list, not for a company whose product is a processing activity. The [duties determination](\u002Fgdpr\u002Fduties) turns the record on for every company that answers \"no\" to \"is the processing occasional\", whatever the headcount, and that is the reading this article works from.\n\n## The seven fields of a controller's record, Article 30(1)\n\nArticle 30(1) requires each controller and, where applicable, the controller's representative, to maintain a record of processing activities under its responsibility, in writing, including in electronic form (paragraph 3). The record contains seven things:\n\n**(a) The name and contact details** of the controller and, where applicable, the joint controller, the controller's representative and the data protection officer. One block, reused on every record; it changes when you appoint an officer or a representative.\n\n**(b) The purposes of the processing.** One purpose per record is the discipline that keeps the rest honest: \"customer accounts and billing\", \"recruitment\", \"product analytics\" are three records, not one.\n\n**(c) A description of the categories of data subjects and of the categories of personal data.** Customers' administrators and end users; staff and applicants; the fields you hold about each: identity, contact, account, usage, payment.\n\n**(d) The categories of recipients** to whom the personal data have been or will be disclosed, including recipients in third countries or international organisations. This is the list of your processors and the customer's other vendors you pass data to; it is the same list Article 28 asks you to contract with.\n\n**(e) Where applicable, transfers of personal data to a third country** or an international organisation, including the identification of that third country and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards. For a company on a US-headquartered cloud, this is the field where the adequacy decision, the standard contractual clauses or the derogation is named per transfer.\n\n**(f) Where possible, the envisaged time limits for erasure** of the different categories of data. Account data for the life of the contract plus the retention your invoicing law sets; logs for ninety days; applicant data for six months. The retention schedule lives here, per category.\n\n**(g) Where possible, a general description of the technical and organisational security measures** referred to in Article 32(1). Not the whole ISMS: a paragraph that says encryption at rest and in transit, access control, backups, logging, and the certificate you hold.\n\n## The four fields of a processor's record, Article 30(2)\n\nArticle 30(2) requires each processor and, where applicable, the processor's representative, to maintain a record of all categories of processing activities carried out on behalf of a controller. For a SaaS, one record per customer or per customer segment, with four fields:\n\n**(a) The name and contact details** of the processor or processors and of each controller on behalf of which the processor is acting, and of the controller's or processor's representative and data protection officer.\n\n**(b) The categories of processing** carried out on behalf of each controller: storage, hosting, analytics, support access, backups.\n\n**(c) Where applicable, transfers** to a third country or an international organisation, with the same documentation as the controller's record.\n\n**(d) Where possible, a general description** of the technical and organisational security measures referred to in Article 32(1).\n\nThe processor's record is the document your customers' records rely on. When a bank customer fills its own field (d) with your name, the categories and transfers it writes are the ones you told it in this record and in the Article 28(3) contract; the two documents have to agree.\n\n## What ISO 27701 evidences, field by field\n\nISO\u002FIEC 27701 extends an ISO 27001 management system to privacy, and its Annex A (controllers) and Annex B (processors) carry a control for records related to processing PII, A.7.2.8 and B.8.2.6 respectively, whose implementation is exactly the record above. The transfer fields are evidenced by the transfer controls, A.7.5.1 to A.7.5.4 for a controller and B.8.5.1 and B.8.5.2 for a processor; the retention field by A.7.4.7; the recipients by the disclosure record of A.7.5.4. The page that writes the record names the control behind each field, in StandardOS's reading; the Regulation names no standard and grants no presumption of conformity, and the record is what the supervisory authority reads, not the certificate.\n\n## Writing it\n\nThe [record-of-processing page](\u002Fgdpr\u002Frecord-of-processing) asks for the role, the company, the activity, and then one input per point of the paragraph, labelled with the point verbatim in your language. The output is the record as a document, to copy into your system or download as Markdown. One record per activity; five to ten records cover a typical software company, and the first is the one every other GDPR duty refers back to: the [impact assessment](\u002Fgdpr\u002Fduties) is done per activity in the record, the breach notification names the categories of data subjects and data from the record, and the transfer ground for every sub-processor is written in field (e).\n",1789383984503]