The data classification decision record: why the sensitivity model you configured determines your access control gap and your breach notification surface

A 31-person SaaS company built a sales productivity tool for B2B software teams. The product helped account executives track outreach history, prepare for customer calls, and log meeting outcomes. By the company's third year, the product stored a meaningful volume of contact records: names, email addresses, phone numbers, company affiliations, and the full-text notes that account executives entered after meetings. The engineering team had designed the schema pragmatically over eighteen months of iterative product development — a contacts table, a meetings table, a users table for the account executives themselves, an activity_log table for product usage telemetry, and a set of supporting tables for tags, notes attachments, and pipeline stages. None of the schema design decisions had been accompanied by a classification of the data each table handled. The engineers knew their own schema and knew what was in each table. The knowledge was distributed across the engineering team as shared context, not documented as a classification artifact.

In the company's third year, the product team hired a junior data analyst to build an internal analytics dashboard. The goal was to understand how account executives were using the product — which features drove engagement, how often users logged meeting notes, what the distribution of pipeline stages looked like across accounts. The analyst connected to the production PostgreSQL database using the shared read role that the engineering team used for local development queries — a role that had been granted SELECT access to all tables in the production database when the database was first provisioned. He wrote SQL queries joining the users, contacts, and activity_log tables to build feature adoption metrics. The resulting views included the names and email addresses of both the account executives who were the company's direct customers and the contacts those account executives had entered into the product — individuals who were data subjects under GDPR and who had not consented to having their information used for the company's internal analytics. No one reviewed the queries before they became the basis of the dashboard. There was no policy distinguishing internal analytics data from the contact records that were personal data belonging to third parties. The distinction existed implicitly in the engineers' mental model of the database, but that mental model had never been written down as a classification.

The dashboard was shared in the company's #analytics Slack channel and was accessible to anyone in the Slack workspace. Four months after the dashboard was built, a freelance consultant was hired for a growth analysis project and added to the workspace as part of her onboarding. She accessed the dashboard as a matter of course — it was the obvious place to start understanding the company's data — and exported portions of the contact record data to a Google Sheet to conduct her cohort analysis. The export was not flagged by any system. The analyst who had built the dashboard had not labelled it as containing personal data of third parties. There was no access review triggered by the consultant's export because there was no classification that would have triggered a review.

Twelve months later, the company's legal counsel began preparing for a GDPR compliance review prompted by an enterprise prospect's vendor assessment questionnaire. The first question in the questionnaire was a request for the company's Article 30 record of processing activities — the documentation of what personal data the company processes, on what legal basis, for what purpose, with what retention period, and who has access to it. Article 30 had been in force since 2018. The company did not have a record. Assembling one required the legal counsel and two engineers to audit the production database schema table by table, trace each table to its data flows and downstream consumers, enumerate the access roles and who held each role, and identify every system and integration that read from or wrote to the database. The audit took three weeks. During the audit, the team discovered that the internal analytics dashboard was querying contact records — personal data of third parties who had not consented to this use — and that the consultant had exported some of those records to a Google Sheet that was still in her Google Drive. Remediating the situation required a legal assessment of whether the export constituted a reportable breach under GDPR Article 33, notification to the company's customers who were data controllers for the contact records their account executives had entered, and a revised data processing agreement with the consultant covering the period during which she had held the exported data. None of this remediation had been triggered by a deliberate bad decision. It had accumulated from the absence of a classification that would have made the contact records' sensitivity tier visible at the point when the analytics access was first granted.

A 38-person SaaS company built a project management tool for creative agencies. The product was well-regarded in its niche, had a stable technical foundation, and had recently added its first enterprise customers. The engineering team ran a tight incident response process: documented runbooks, a clear escalation chain, a Slack channel for live incident coordination. What the team did not have was a pre-computed data classification that mapped each database table to a sensitivity tier and specified which data subjects' personal data each table contained.

In the company's fourth year, GitHub's automated secret scanning service sent a notification that a repository had been briefly made public. The repository was an internal tooling project — a collection of environment setup scripts that a senior engineer had built to automate new hire onboarding. She had included a .env.example file as a template, but one branch included a committed .env file containing actual production credentials. The branch had been pushed to GitHub during a rushed session the night before a team offsite; the engineer had intended to set the repository to private before pushing and had not. The repository was public for approximately four minutes before a Slack alert from GitHub's security monitoring prompted a team member to change the visibility setting.

The incident response team convened within the hour. The technical scope was clear: one set of PostgreSQL credentials had been exposed in a public repository for four minutes. The credentials belonged to a database role that had been created in the company's early development phase to allow engineers to run queries from their development environments — a convenience role with SELECT access across all tables in the production database. The technical response was straightforward: rotate the credentials immediately, audit GitHub's repository access logs for any clones or forks during the four-minute window, verify through the database's connection audit log that the credentials had not been used to authenticate against production during the exposure window.

The GDPR question was not straightforward. The company's obligation under Article 33 was to notify the supervisory authority within 72 hours of becoming aware of a personal data breach if the breach was likely to result in a risk to the rights and freedoms of natural persons. The risk assessment required answering three questions: what categories of personal data were accessible through the compromised role, whose data was accessible, and what the realistic consequences of access during the four-minute window were. None of these questions could be answered without knowing which of the production database's tables contained personal data, which categories of personal data those tables contained, and which data subjects were represented. The incident response team knew the role had SELECT access to all tables. They did not have a documented classification of which tables contained personal data and which did not.

The data model audit took four days. The engineering team worked through the production schema table by table: project names and task descriptions in free-text fields that might contain personal references; user profiles with names, email addresses, and profile photos; time-tracking records tied to individual users; comments and messages exchanged between team members and with external stakeholders who were not the company's direct customers; file attachments whose contents could not be enumerated without reviewing them. The free-text fields — task descriptions, comments, messages — had the potential to contain special-category data entered by users in the course of their work, including health information, political opinions, or other Article 9 categories, though the company had no way to enumerate this without a full content review. By the time the audit was complete, the 72-hour notification window had closed. The company filed a late notification with its supervisory authority. No penalty was imposed in this case. The company's legal counsel documented in her incident review that the delay was entirely attributable to the absence of a pre-existing classification: had the incident response team been able to read the sensitivity tier and subject population of each table from a classification registry rather than reconstructing it from the schema and the application code, the risk assessment would have taken hours rather than days, and the 72-hour window would not have closed before the notification was filed.

A 44-person SaaS company built a patient engagement platform — a scheduling and communication tool for outpatient healthcare providers. The product was not a clinical application. It did not handle protected health information as HIPAA defines it. What it did handle were the names, dates of birth, phone numbers, appointment records, and communication histories of patients at its clinic customers. The engineering team had a strong technical culture: good test coverage, careful database design, a well-maintained API surface. The one thing the team had not formalized was a data classification model for the production database — a mapping of each table to a sensitivity tier that specified what categories of data it contained and what access obligations that sensitivity implied.

In the company's second year, the product team hired two data analysts to build reporting features for clinic customers. The analysts were given a read-only PostgreSQL role on the production database to allow them to explore the data model and draft the SQL queries that would underpin the analytics features. The role had SELECT access to all tables in the production database — the same broad grant that the engineering team's development role used. The intent had been for the access to be a temporary exploration phase after which the analysts would migrate to a purpose-built analytics schema with appropriate redaction. The temporary access became permanent when the analysts began building reports that clinic customers relied on in their daily workflows. The migration to the analytics schema was added to the backlog and remained there.

Over the following fourteen months, the analytics team grew from two people to eight. Each new hire was given the same production read role as part of their standard onboarding, using a runbook that had been written when the team was two people and had not been updated as the team grew or as the production schema evolved. During those fourteen months, the production database had grown substantially: a secure messaging feature had added a communication_log table storing the full text of SMS and email communications sent from the platform to patients; a machine learning pipeline the engineering team had shipped in the company's third year had added an ml_risk_scores table storing health-related risk indicators derived from patient engagement patterns — AI-generated proxy metrics for patient health status; and a payment processing integration had added a payment_methods table storing Stripe token references and masked card details. None of these additions had prompted a review of who had SELECT access to the new tables. The production read role was a database-level grant. When new tables were added to the production database, the role acquired SELECT access to them automatically. No alert was triggered. No access review was required by the onboarding runbook. The eight members of the analytics team had read access to three tables — communication_log, ml_risk_scores, payment_methods — that had been added to the production database after the access role was created, and whose sensitivity tiers had never been reviewed against the authorization level the role had been granted for.

The company's first SOC 2 Type II audit began in the company's fourth year. The auditor's access control testing included a mapping of which users could query which tables in the production database. The mapping showed eight members of the analytics team with SELECT access to all three of the sensitive tables. The communication_log table contained the full text of SMS and email messages sent to patients — private communications. The ml_risk_scores table contained health-adjacent risk indicators derived from patient behavior patterns — data that, depending on the jurisdiction and the clinic's specialization, could be health-related personal data. The payment_methods table contained financial data. The auditor flagged the access as a finding: eight analysts had production read access to data whose sensitivity tier, under the company's own data processing agreements with clinic customers, required restriction to authorized clinical and billing personnel. The company had been unaware of the finding not because anyone had made a bad decision, but because no one had made a classification decision — the sensitivity of the tables had been known to the engineers who designed them, carried as shared context, and never documented in a form that the access grant process could consume.

The immediate remediation — revoking the broad production read role from the analytics team — broke three executive-facing dashboards that the head of sales and the two clinical operations leads used daily. The dashboards were pulling SQL directly against the production database. Rebuilding the access model required creating table-level access grants for the data the analytics team legitimately needed, designing an anonymized analytical layer that excluded the sensitive tables and provided aggregated views of the data that satisfied the reporting requirements without exposing raw records, and migrating the production SQL queries in the dashboards to the new schema. The project took six weeks of engineering time. The SOC 2 finding, the six-week remediation, the three weeks of dashboard unavailability, and the disclosure to the company's clinic customers about the access finding had a single root cause: no one had classified the production database's tables at the time the access role was first granted, and no classification review had been triggered by the fourteen months of schema evolution during which the role's access surface had grown from four tables to seventeen.

Structural properties set by the data classification decision

Three structural properties are determined when an engineering team establishes — or fails to establish — a data classification model for its product: how clearly the sensitivity tier of each table and field is defined and accessible at the time access decisions are made, how completely the classification registry maps the data processing landscape so that breach notification scope can be determined from documentation rather than reconstruction, and how robustly the access tier enforcement model is coupled to the classification rather than to a point-in-time understanding of the schema that grows stale as the schema evolves. None of these are labeled as decisions at the time the first database schema is designed — they emerge from the implicit sensitivity understanding that the founding engineers carry as shared context and that does not survive team growth, role changes, or the passage of time.

Property 1: The sensitivity tier model and the access control gap. Access control decisions are downstream of classification decisions — the question of who may query a given table is not answerable without first knowing what the table contains and how sensitive that content is. When the sensitivity model is documented, the access grant process is a matching exercise: does the access level requested align with the access permissions the classification specifies for the sensitivity tier of the data being accessed? When the sensitivity model is implicit, the access grant process is a trust exercise: does the person granting access believe that the data being accessed is appropriate for the role being granted? The gap between these two processes is the access control gap, and it grows with team size, role turnover, and schema evolution. The engineer who grants the analytics team access to the production database in year one trusts that the engineers who need the access understand what they are accessing. The engineer who processes the access request for the seventh analytics hire in year three has no mechanism to verify that the production read role's access surface, as it exists in year three, is appropriate for the new hire's function — unless the classification registry specifies which tables the role can access at which sensitivity level and the access grant process requires verification against the registry. The decisions never written down in the data classification domain are not the decisions to collect personal data — those are visible in the schema, the API endpoints, and the privacy policy. They are the sensitivity tier of each table, the categories of data subjects whose records each table contains, the maximum access level that each role type may hold for each tier, and the classification review trigger that would surface when a new table added to a previously-classified database changes the access surface of an existing role. The new CTO onboarding problem in the data classification domain is specific: the incoming technical leader asks "what personal data does the product handle and who can access it?" and the honest answer is "we know, but we haven't written it down" — an answer that, in the context of an enterprise sales process, a regulatory inquiry, or a security incident, is identical in its practical effect to "we don't know."

Property 2: The classification registry and the breach notification surface. GDPR Article 33's 72-hour notification window is not a deadline to complete an investigation — it is a deadline to notify the supervisory authority that an investigation is underway and that a breach has occurred. The notification requires the controller to specify, to the extent possible at the time of notification, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned. Providing this information requires knowing which tables the compromised access vector could reach, which of those tables contain personal data, which categories of personal data they contain, and whose records are in those tables. A pre-existing data classification registry makes each of these queries a lookup rather than an investigation. An absent classification registry makes each of these queries a real-time audit. The four-day audit that caused the missed notification window in the second scenario above was not an unusually complex or unusually large database — it was a standard-sized project management schema for a 38-person company. The delay was not a function of complexity; it was a function of the audit being conducted for the first time, under incident pressure, against a schema that had no pre-existing classification. The consent management decision record connects at the lawful basis layer: the classification registry must record not only the sensitivity tier of each table's data but also the lawful basis on which each category of personal data is processed — consent, legitimate interest, contract performance, or legal obligation — because the breach notification risk assessment requires understanding whether the data subjects have a reasonable expectation that the data would be held and whether the exposure changes the risk calculus against the original lawful basis; this coupling is only possible when the classification records the lawful basis alongside the sensitivity tier. The audit log decision record connects at the access history layer: the breach notification scope assessment requires not only knowing what the compromised role could access in principle but also whether there is evidence that the access occurred; a complete audit log of query activity against personal data tables — who queried, when, what tables — compresses the window from "potentially compromised for four minutes" to "no query activity in the audit log during the four-minute window"; without the audit log, the scope is the worst case, which may trigger a notification obligation that an audit log would have allowed the controller to rule out.

Property 3: The access tier enforcement model and the creep failure mode. Database-level access grants — roles with SELECT privileges on an entire database rather than on named tables — are the structural enabler of access tier creep. When a role is granted at the database level, every table added to the database after the grant is automatically accessible to the role holder without any subsequent decision about whether the new table's data is appropriate for the role. The creep is silent: no individual decision is wrong, no alert fires, no review is triggered. The only mechanism that catches the creep is a periodic review of the access surface of existing roles against the current schema, which requires knowing the current schema's classification to evaluate whether the creep has produced an access surface that exceeds the role's authorization level. Without a classification registry, the periodic review is not possible — there is no documented access-tier model to compare the current access surface against. The gap accumulates until an audit, an incident, or a compliance review forces the comparison. The access control model decision record connects at the enforcement layer: the access control model specifies the role types that exist and the maximum access level each may hold; when the access control model is specified at the role-type level (analytics roles may not access tables classified as regulated) rather than at the individual table level, and when new tables are classified before they go to production, the enforcement is structural rather than procedural — the classification feeds the access control policy directly and the creep failure mode requires an explicit policy override rather than an implicit omission. The multi-tenant data isolation decision record connects at the tenant boundary layer: in multi-tenant products, the classification registry must include the tenant-scoping requirement for each table — which tables contain cross-tenant data that requires tenant-scoped query filters and which contain single-tenant data that is safe to aggregate across tenants; an analytics role with SELECT access to a cross-tenant table without a tenant-scoping filter is both a data classification access failure and a tenant isolation failure, and the two failure modes are not distinguishable in the access grant process unless the classification registry specifies which tables carry the tenant-scoping requirement.

What the founding session records and what it omits

The founding session that designs the first database schema records the schema: the tables, the fields, the relationships, the indexes. If the engineers are thorough, it records the rationale for significant schema choices — why a particular normalization decision was made, why a field is stored as text rather than an enum, why a table was split rather than kept together. What the founding session does not record is the sensitivity classification of the data each table stores. The engineers who design the first schema know whether the users table contains personal data — they put the email and name fields there. They know whether the activity_log table contains behavioral data tied to identifiable users. They know whether the payment_methods table contains financial data. This knowledge is embedded in the schema design itself. It is not documented as a sensitivity classification because the classification feels redundant — the schema shows what the table contains, and anyone who can read the schema can infer the sensitivity. The inference holds for the founding team with shared context. It does not hold for the junior analyst hired in year three to build the internal dashboard, who reads the schema and does not know that the contacts table contains third-party personal data rather than first-party user data and that the distinction matters for the analytics access he is about to enable. It does not hold for the engineer processing the access grant request for the seventh analytics hire who does not know that the production read role's access surface includes three tables added in the past eighteen months whose sensitivity tiers were not reviewed against the role's original authorization level.

The omissions are structurally similar across the decision record series: benign at founding, when they are covered by the founding team's shared context, and compounding as the team grows, the schema evolves, and the original engineers move on or change roles. The sensitivity tier omission is not a problem when the engineering team is five people who all know the schema intimately and review every access grant request themselves. The breach notification scope omission is not a problem until the first credential exposure, at which point the absence of a pre-computed scope model becomes the rate-limiting step in the incident response process. The access tier enforcement gap is not a problem when the database has four tables and one access role. It becomes a problem at scale when the database has seventeen tables, three access roles, and eight people in the analytics team — none of whom were present when the original access grant decisions were made and none of whom have a classification registry to check their access level against. The data retention decision record connects at the lifecycle layer: retention periods are determined by sensitivity tier — personal data under GDPR has a retention obligation tied to the purpose for which it was collected; without a classification, retention policy cannot be applied correctly at the table level; tables whose records should be purged after a defined retention period remain populated indefinitely because the retention obligation was never recorded in a form that the purge automation could consume. The compliance automation decision record connects at the evidence layer: SOC 2, GDPR, and HIPAA-adjacent compliance frameworks all require evidence that access to sensitive data is controlled and periodically reviewed; the classification registry is the foundational artifact that compliance evidence builds on — without it, every compliance audit requires reconstructing the classification from the schema and the application code rather than producing a classification document that was maintained before the audit began. The WhyChose extractor finds the data classification discussions in your AI session history — the conversation where the schema was first designed and someone asked what kind of data each table would contain, the thread where the analytics access was discussed and the word "sensitive" appeared alongside the table names, the exchange where the GDPR review came up and the question of which tables contained personal data was answered in passing without anyone turning the answer into a document — and surfaces those decisions so you can assess which sensitivity assumptions still hold against the current schema, the current access role population, and the current compliance framework.

The data classification ADR: five sections

Section 1: Sensitivity tier definitions and obligation mapping. Specify four sensitivity tiers before the first table is classified. Tier 1 — Public: data that may be disclosed to any person without restriction; product documentation, published blog content, marketing copy; no access restrictions, no breach notification obligation, no retention requirement beyond operational need. Tier 2 — Internal: data that is intended for internal use and should not be disclosed outside the company but whose exposure would not constitute a breach of legal obligation; aggregate product metrics without PII, internal operational records, non-PII application logs; access restricted to company employees and contractors under NDA, no regulatory breach notification obligation, retention at operational discretion. Tier 3 — Confidential: data that identifies or could identify a natural person, including names, email addresses, IP addresses, device identifiers, behavioral data linked to identified individuals, and any data whose combination could identify a person; GDPR personal data as defined in Article 4; access restricted to employees and contractors with a documented need, breach notification obligation under GDPR Article 33 if the exposure is likely to risk rights and freedoms, retention limited to the purpose for which the data was collected. Tier 4 — Regulated: data in special categories under GDPR Article 9 (health, genetic, biometric, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life or sexual orientation), financial data subject to PCI DSS or equivalent, or data subject to sector-specific regulation such as HIPAA-adjacent health-related inference data; strictest access restrictions, mandatory breach notification regardless of risk assessment, retention governed by the specific regulatory framework. Map each tier to its obligation profile at the time the tiers are defined — not "sensitive" as a label but the specific access requirements, notification triggers, and retention rules the tier carries. Connect this section to the consent management decision record: Tier 3 and Tier 4 tables must each carry a documented lawful basis — consent, legitimate interest, contract performance, or legal obligation — as a required field in the classification registry; the lawful basis determines the scope of permissible processing and is required for the breach notification risk assessment; tables without a documented lawful basis cannot be assessed for notification obligation because the risk calculus depends on whether data subjects have a reasonable expectation of the processing.

Section 2: Table and field classification registry. Specify the classification registry format before the first table is classified: a structured document — a YAML file committed to the repository alongside the schema migrations, a database table in an internal tooling schema, or a maintained document in the team's knowledge base — with one entry per production table. Required fields for each entry: the table name, the sensitivity tier, the categories of data stored in the table (personal data, financial data, health-adjacent inference, communication content, product telemetry), the categories of data subjects whose records the table contains (direct customers, end users of customer products, employees, third parties), the lawful basis for processing Tier 3 and Tier 4 tables, the date of the most recent classification review, and the owner responsible for keeping the classification current. The registry is not a one-time artifact — it is a living document maintained as the schema evolves. The requirement: every database migration that creates a new table or adds fields to an existing table must include a classification entry or update as part of the migration review before the migration deploys; the code review for any migration touching a Tier 3 or Tier 4 table must include confirmation that the classification registry has been updated; migrations that add new tables without a classification entry are rejected at code review. The field-level classification is required for Tier 4 tables and recommended for Tier 3 tables: a table classified at Tier 3 for containing email addresses may also contain a free-text notes field whose contents could include Tier 4 health information entered by users; the field-level classification makes the Tier 4 risk visible at the field level rather than requiring the table-level classification to be elevated to Tier 4, which would impose Tier 4 access restrictions on all fields in the table including those that carry no Tier 4 data.

Section 3: Access tier model and least-privilege enforcement. Specify the access tier model: the mapping from sensitivity tiers to permitted access role types, with maximum access levels defined before any access grant is made. Tier 1 (Public): any authenticated internal user or system role. Tier 2 (Internal): any employee or contractor under NDA; service accounts limited to the tables required for their function. Tier 3 (Confidential): employees and contractors with a documented business need; service accounts with table-level SELECT grants (not database-level grants) approved by the table owner; analytics roles with access limited to anonymized views or aggregated results unless the analytics function requires record-level access and the need is documented and time-bounded. Tier 4 (Regulated): named individuals with a documented role-based need (clinical personnel for health data, billing personnel for financial data); service accounts with the minimum field-level access required for the specific function; analytics roles prohibited from direct access to Tier 4 tables — access is only through pre-approved anonymized or aggregated views that do not expose regulated fields. Enforce the model structurally: prohibit database-level grants for any role that will access Tier 3 or Tier 4 tables; require table-level grants specifying the exact tables the role may access; require the classification registry to be checked as part of every access grant process — the access grant checklist must include a step confirming that the sensitivity tier of every table the new role will access is at or below the access tier permitted for the role type. Connect this section to the access control model decision record: the access control model specifies the role types and their maximum permissions; the classification registry specifies the sensitivity tier of each table; the two together determine the access grant decision for any combination of role type and table; when the two are maintained in sync, the access grant process is a policy enforcement exercise rather than a judgment call; when either is absent, the access grant process is a judgment call against incomplete information, and the judgment accumulates error as the team grows and the schema evolves.

Section 4: Breach notification scope model and incident response protocol. Specify the breach notification scope model before any breach occurs. The scope model is a pre-computed artifact: for each access role in the production system, a mapping of the sensitivity tier of every table the role can access, the categories of personal data accessible through the role, the approximate number of data subjects whose records are accessible, and the notification obligation triggered if the role's credentials are compromised. The scope model is the first document consulted in an incident response for any credential compromise or unauthorized database access — it converts the question "do we have a notification obligation?" from a real-time investigation to a lookup. The model must be kept current as the schema evolves: any change that adds a table to the access surface of an existing role — either through a database-level grant or through a table addition to a database where a database-level grant exists — must update the scope model entry for the affected role; the scope model entry for a role must accurately reflect the current access surface, not the access surface at the time the role was created. Specify the incident response protocol for credential compromise: step one, immediately rotate the compromised credentials and revoke the affected role; step two, audit the connection log for the production database for the period during which the credentials were exposed, identifying any authentication events using the compromised role — if the connection log shows no authentication during the exposure window, document this as the scope determination and assess notification obligation against the access surface the compromised role held, not the access surface a successful attacker would have had; if the connection log shows authentication during the exposure window, consult the access logs for the specific queries executed; step three, read the breach notification scope model entry for the compromised role to determine notification obligation; step four, if notification is required, file within the 72-hour window with the scope information from the scope model. Connect this section to the compliance automation decision record: the breach notification scope model is the artifact that compliance automation frameworks use to automate the notification decision; compliance automation tooling that monitors credential exposure events and triggers notification workflows requires the scope model as input — without it, the automation cannot determine notification obligation and defaults to human escalation, reintroducing the manual audit step that the automation was intended to eliminate.

Section 5: Classification review cadence and reclassification protocol. Specify the review cadence before the first table is classified: an annual full review of the classification registry against the current production schema, and a triggered review on every database migration that creates a new table or adds fields to a Tier 3 or Tier 4 table. Annual review: compare each entry in the classification registry against the current schema; identify tables or fields that have been added since the last review without classification entries; identify tables or fields whose contents have changed in ways that may affect their sensitivity tier, for example a free-text field whose use has evolved from innocuous notes to a field where users regularly enter health-related information; identify Tier 3 and Tier 4 tables whose lawful basis documentation no longer reflects the current data processing purpose. Migration trigger: any migration that adds a new table, adds fields to a Tier 3 or Tier 4 table, changes the purpose of an existing table, or removes a table must include a classification registry update as a required deliverable reviewed in the migration code review; the classification update must be reviewed by the table owner, not only the engineer submitting the migration. Out-of-cycle reclassification triggers: four events require an immediate classification review outside the annual cadence — an access grant request for a role type accessing a table for the first time, which requires verifying the table's current sensitivity tier before the grant is approved; a new integration that writes data to an existing table, which may introduce new categories of data not previously present in the table's classification; a change in the regulatory environment affecting the company's jurisdiction or sector, which may reclassify tables that were previously Tier 3 to Tier 4 or vice versa; and any security incident involving database access, which requires verifying that the classification accurately reflects the sensitivity of the data accessible through the access vector that was involved in the incident. Connect this section to the audit log decision record: the classification review process must be recorded in the audit log — not only the current classification but the history of classification changes, including who reclassified each table, when, and why; the classification history is the evidence artifact for compliance audits demonstrating that the company has actively maintained its data classification model rather than produced it reactively in response to an audit finding; the absence of a classification change history is not neutral evidence — an auditor who sees a classification registry with no recorded history of updates and reviews will reasonably conclude that the registry was assembled for the audit rather than maintained before it, which is a weaker compliance posture than a registry with a documented review cadence even if the two registries contain identical classifications at the time of the audit.

FAQ