Building a data governance operating model for a fashion house
A returns spike hits your e-commerce team on a Monday. The merchandising VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.View full definition → blames sizing data. The store operations lead says the return reason codes are wrong. The digital team insists their tracking is fine. Three teams, one dataset, zero owners. Nobody can fix it because nobody owns it.
This is the core failure a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → operating model prevents. Governance is not paperwork. It is deciding, in advance, who owns which data, who can change it, and who gets consulted when it breaks.
Why fashion needs its own governance model
Fashion data is unusually fragmented. A single customer touches your brand across a flagship store, an outlet, a website, a wholesale partner (a department store selling your label), and a resale platform. The same physical product carries different identifiers in each channel.
Add fast product turnover (new collections every few weeks), seasonality, and heavy use of customer data for personalization, and you get a governance problem that generic templates do not solve.
Three domains matter most:
- Customer domain: loyalty profiles, consent, purchase history, style preferences.
- Product domain: the SKU (Stock Keeping Unit, the unique code for each size/color variant), materials, pricing, imagery.
- Transaction domain: sales, returns, refunds, channel attributionattributionA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results.View full definition →.
Each needs a clear owner. That owner is called a data stewarddata stewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.View full definition →.
Stewardship roles, defined
A data owner is a senior accountable executive (usually a VP or director) who answers for a domain's quality and compliance. They rarely touch data day to day.
A data steward is the hands-on person who defines the rules, monitors quality, and resolves disputes for a domain. Think of them as the domain's referee.
A data custodian is usually IT or engineering. They run the systems and enforce access controls but do not decide business rules.
Mapping stewards to fashion domains
| Domain | Data Owner | Data Steward | Custodian |
|---|---|---|---|
| Customer | Chief Customer Officer | CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →/loyalty manager | IT/platform team |
| Product | Head of Merchandising | PIM manager | IT/platform team |
| Transaction | Head of E-commerce + Retail Ops | Finance data analyst | IT/platform team |
A PIM is a Product Information Management system, the master source for product attributes (fabric, fit, care instructions). If your PIM says "silk" and your website says "silk blend," someone must own that discrepancy. That is the product steward.
RACI: who does what when data changes
RACI stands for Responsible, Accountable, Consulted, Informed. It is a simple grid that removes ambiguity. For each task:
- Responsible: does the work.
- Accountable: owns the outcome (only one person).
- Consulted: gives input before it happens.
- Informed: told after it happens.
Worked example: changing a product's core attribute
Say merchandising wants to reclassify a jacket from "outerwear" to "blazers" mid-season. This changes site navigation, search filters, and reporting.
| Task | Merch Steward | E-com Steward | Store Ops | IT Custodian |
|---|---|---|---|---|
| Approve reclassification | A | C | C | I |
| Update PIM record | R | I | I | I |
| Republish to website | I | R | I | C |
| Update store systems | I | I | R | C |
Notice only one A per row. That is the rule. When two people think they are accountable, nothing gets decided. When nobody is, nothing gets fixed.
Build one RACI per recurring data event: new SKU onboarding, customer consent withdrawal, return reason code changes, price overrides. These are your governance backbone.
The privacy layer you cannot skip
Fashion houses run on customer data, so privacy law is not optional.
In the European Union, the GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → (General Data Protection Regulation) governs how you collect and use personal data. It requires a lawful basis for processing, gives customers rights to access and delete their data, and mandates that you honor consent. Fines can reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → up to 4 percent of global annual revenue (a well-established figure in the regulation text).
In the United States, there is no single federal law. The key state law is the CCPA (California Consumer Privacy Act), extended by the CPRA (California Privacy Rights Act), giving California residents rights to know, delete, and opt out of the sale of their data. Other states (Virginia, Colorado, Connecticut, and more) have passed their own laws, so a US fashion brand faces a patchwork.
For a plain overview of GDPR obligations, the European Commission's own page is a solid free starting point: What the GDPR requires.
Governance meets privacy: consent as owned data
Consent is data. It has an owner (the customer steward), a lawful basis, and a lifecycle. When a customer unsubscribes from email in Paris, that withdrawal must propagate to every system: CRM, email platform, personalization engine, and any wholesale partner sharing.
Your RACI must include a "consent withdrawal" event. Miss it and you send marketing to someone who opted out. That is a violation, not a bug.
Practical data checks and audits
Governance without checks is just a diagram. Here are concrete, runnable controls.
Data qualityData qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → checks
Run these on a schedule, not once:
- Completeness: every active SKU has fabric, care, and country of origin populated. Missing country of origin can create customs and compliance issues.
- Uniqueness: no duplicate customer profiles (the same person with two loyalty accounts inflates your active-customer count).
- Validity: return reason codes match an approved list.
- Consistency: PIM price matches website price matches POS (Point of Sale) price.
A simple validity check in SQL:
-- Flag transactions with return reason codes not in the approved list
SELECT transaction_id, return_reason_code
FROM transactions
WHERE is_return = TRUE
AND return_reason_code NOT IN (
SELECT code FROM approved_return_reasons
);Any rows returned are governance failures with a named owner (the transaction steward) who must resolve them.
Consent and access audits
Quarterly, verify:
- Every marketing send maps to a valid, current consent record.
- Access permissions match role (a seasonal store associate should not query full customer purchase history).
- Data retention: profiles inactive beyond your stated retention period are deleted or anonymized. Publishing a retention period and then ignoring it is worse than having none.
Knowledge check
1. The opening scenario describes three teams blaming each other over a returns dataset that nobody can fix. What core governance failure does this illustrate?
2. Why do generic data governance templates tend to fail in a fashion house?
3. A dispute arises over how return reason codes should be defined and standardized in the transaction domain. Who is the appropriate role to resolve this day-to-day?
4. Select ALL correct answers that accurately distinguish the three stewardship roles.
Select all the correct answers.
5. Select ALL correct answers about the three key data domains in the fashion governance model.
Select all the correct answers.
Standing up the operating model
You do not need a 40-person data office. Start lean.
Step 1: Charter a governance council. One owner per domain (customer, product, transaction) plus a privacy lead (often a DPO, Data Protection Officer, which GDPR requires for many companies processing personal data at scale). Meet monthly.
Step 2: Publish a data catalog. A plain list of your critical data assets: what each field means, where it lives, who owns it. Ambiguity about what "customer lifetime value" means across teams causes more damage than most breaches.
Step 3: Define your critical data events and write a RACI for each. Start with the five that break most often: new SKU onboarding, price change, return reason updates, consent withdrawal, customer profile merge.
Step 4: Instrument the checks. Automate the quality and consent checks above. Route failures to the named steward with a service-level target (for example, product data gaps resolved within 48 hours).
Step 5: Audit and report. A one-page monthly scorecard: completeness rate by domain, open governance issues, consent exceptions. The owner presents it. Visibility drives accountability.
A note on wholesale and resale partners
When a department store or resale platform sells your product, data flows both ways. Your governance model must specify what you share, under what agreement, and who owns the quality of inbound partner data. A data sharing agreement should name the lawful basis and the retention terms. Do not let partner data quietly enter your systems ungoverned.
Key Takeaways
- One accountable owner per data domain, always. Customer, product, and transaction each need a named data owner and a hands-on steward. Shared accountability means no accountability.
- RACI turns governance from theory into action. Write one grid per recurring data event (SKU onboarding, price change, consent withdrawal). Exactly one "Accountable" per task.
- Consent is governed data with a lifecycle. Under GDPR (EU) and CCPA/CPRA (US), a withdrawal must propagate everywhere. Treat it as a first-class data event, not an afterthought.
- Checks make governance real. Automate completeness, uniqueness, validity, and consistency checks, then route failures to the responsible steward with a resolution deadline.
- Govern the edges too. Wholesale and resale data flows need sharing agreements naming lawful basis, retention, and quality ownership before the data enters your systems.