# Data Governance for Growing Companies: Ownership, Access and Audit > A practical data governance plan for growing companies: name an owner for each dataset, control who can see it, and audit changes without a heavy committee. - URL: https://weaveward.com/blog/data-governance-growing-companies - Published: 2026-07-07 - Updated: 2026-07-07 - Category: Data & Dashboards - Tags: data governance, data ownership, access control, audit trail, uu pdp - Author: Weaveward Team The Monday meeting opens with two revenue figures. Finance has one number from the accounting system, sales has another from the dashboard, and nobody can say who changed the formula last month. It looks like a data problem, but it is really a governance problem. Data governance is a short list of decisions: who owns each important dataset and metric, who may see or change it, and how you can prove later what happened to it. For a company of 30 to 500 people, those decisions fit in a few pages and a handful of settings in tools you already pay for. You do not need a committee or an expensive platform to start. This guide covers the three parts that matter most at your stage, ownership, access and audit, followed by a realistic rollout plan and the mistakes that make governance efforts stall. ## Why data governance gets urgent as you grow In a small company, the founder knows where every number comes from. Growth breaks that. You add a POS, seller centers on Tokopedia and Shopee, an accounting system, an HRIS and a CRM, and each team builds its own spreadsheets on top. The symptoms are familiar: - Two dashboards show different figures for the same metric, and both are "correct" by their own definition - Customer lists with names and WhatsApp numbers are exported and passed around in chat groups - Former employees still have access to shared drives or the BI tool months after they left - Nobody knows which table or spreadsheet feeds a report, so nobody dares to change anything - A supplier's bank account number changes in the system, and nobody can tell who changed it Few of these are technology failures. They come from missing decisions about responsibility. The technical side of bad numbers is covered in our article on [why dashboards mislead and how to fix data quality](/blog/data-quality-dashboards); governance is the layer above it that makes those fixes stick. ### The legal reason: UU PDP Indonesia's Personal Data Protection Law, Law No. 27 of 2022 (UU PDP), became fully enforceable when its two-year transition ended in October 2024. A data controller must process personal data on a lawful basis, keep it secure, honor the rights of the people the data describes and notify those people and the supervisory authority in writing within 3 x 24 hours of a data protection failure. You cannot meet those obligations if you do not know where personal data lives and who can touch it. Our guide to [what apps must do to comply with UU PDP](/blog/uu-pdp-compliance-apps) explains the obligations in more detail. ## Ownership: one accountable name per dataset Governance starts with names, not tools. Every dataset that drives decisions or carries legal risk needs a person who answers for it. ### The four roles you need | Role | What they decide or do | Typical person in a 100-person company | |---|---|---| | Data owner | Who may access the data, what "correct" means, how long it is kept | Head of Sales for customer data, Finance Manager for revenue and payables | | Data steward | Maintains definitions, checks quality, fixes records | A senior admin or analyst inside that team | | Data custodian | Runs storage, backups and permissions as instructed | IT lead, in-house developer or your vendor | | Data consumer | Uses the data within the agreed rules | Everyone else, including dashboards and AI tools | The owner is a business role. IT can implement access rules, but it should not decide whether the marketing team may download the full customer list. That decision belongs to whoever is accountable for the customer relationship. ### Start with critical data elements Do not try to govern everything at once. List the 10 to 20 data elements whose errors would cost money, break compliance or mislead management: - Customer master data, such as names, phone numbers, addresses and tax IDs for B2B billing - Product master data and price lists - Sales transactions from the POS, website and marketplaces - Inventory balances per location - Supplier master data, especially bank account details - Employee and payroll data, including BPJS membership numbers Each item gets an owner, a steward and a system of record: the one place where the official version lives. ### Define each metric once Most dashboard arguments are really definition arguments. Does "net revenue" exclude marketplace fees, returns and PPN? Does a "new customer" mean a first order ever, or a first order this year? Write each key metric down with its formula, source tables, owner and the date it last changed. Keep this metric glossary where people look, ideally inside the BI tool next to the chart. Our guide to [KPI dashboards for executives](/blog/kpi-dashboards-for-executives) helps you pick which metrics deserve this treatment first. ## Access: the minimum each role needs Access rules protect you from leaks, fraud and honest mistakes. The principle is least privilege: people get the access their job requires, and you can explain every grant. ### Classify data into four levels 1. **Public**: website prices, published product content, press materials 2. **Internal**: operational reports, stock levels, SOPs 3. **Confidential**: margins, supplier contracts, payroll totals, business plans 4. **Restricted**: personal data, especially what UU PDP calls specific personal data, such as health information, biometric data, personal financial data and children's data Each level gets a default rule. Restricted data, for example, is masked in dashboards unless a role needs it, cannot be exported without the owner's approval and never goes into consumer AI chatbots. ### Roles, rows and exports Grant access to job roles rather than individuals, so a new branch manager gets the right permissions on day one. Most BI tools and databases support row-level security, which lets a manager in Surabaya see only Surabaya transactions in the same dashboard head office uses. Treat export as a separate permission from viewing. Many leaks start with a legitimate viewer downloading a full table to a laptop. Clear rules like these are also what make [self-service analytics](/blog/self-service-analytics) safe, because people can explore freely inside a space that already hides what they should not see. ### Joiners, movers and leavers Access drifts unless someone owns the routine: - HR tells IT and the data owners on the day someone joins, changes role or leaves - Access is removed on the last working day, including BI tools, shared drives and SaaS admin panels - Shared logins, such as one marketplace account used by five people, are replaced with individual accounts wherever the platform allows it - Single sign-on is switched on for core tools when your plan supports it - A quarterly review lists everyone with restricted access, and each owner confirms or revokes every grant ## Audit: proving what happened Ownership and access are promises; audit is how you check them. When an auditor, a customer or your own director asks who changed a price, who downloaded the customer list or why last quarter's revenue moved after closing, the answer should come from logs, not memory. ### What to log - Logins and failed login attempts on systems that hold restricted data - Permission changes, especially new admin rights - Exports and bulk downloads from the BI tool, CRM and databases - Changes to master data such as prices, discounts, supplier bank accounts and credit limits - Changes to metric definitions and transformation logic Many SaaS tools offer audit logs only on business or enterprise plans, so check before your next renewal. For your own systems and data warehouse, keep transformation code in version control so that every change to a metric has an author, a date and a reason. Our [beginner's guide to data warehouses](/blog/data-warehouse-beginners-guide) explains where that transformation layer sits. ### Retention and review Decide how long each dataset and log is kept. Indonesian tax and company document rules generally require financial records to be kept for 10 years, so confirm the exact obligations with your accountant. Personal data, by contrast, should be kept only as long as its purpose requires under UU PDP and then deleted or anonymized. Logs nobody reads protect nobody. Put two reviews on the calendar: a monthly look at exports of restricted data and a quarterly access review signed off by each owner. ## A 90-day data governance rollout As a rough planning estimate, assuming one owner per business domain who can give a few hours a week and a small IT or data team doing the setup, a growing company can put a working baseline in place in about three months. Groups with several legal entities or many legacy systems should plan for longer. 1. **Weeks 1 to 2, inventory.** List the systems, spreadsheets and recurring exports that matter. Identify critical data elements and name owners and stewards 2. **Weeks 3 to 4, classify and map.** Tag each dataset with a classification level and record where personal data is collected, stored and shared. This doubles as the start of your UU PDP processing records 3. **Weeks 5 to 8, fix access.** Define roles, apply row-level security, remove orphan accounts and separate export rights from viewing rights. Turn on audit logging wherever it is available 4. **Weeks 7 to 10, define metrics and checks.** Write the glossary for your top 15 metrics and add automated checks for critical data elements, such as duplicate customers or missing tax IDs 5. **Weeks 11 to 12, review and repeat.** Run the first access review, test a leaver scenario end to end, write a one-page incident procedure and book the recurring reviews ### Pitfalls that stall governance - **Buying a catalog tool first.** Catalog software helps once owners exist. Before that, it becomes an empty directory - **Writing a policy nobody reads.** Five rules enforced in your tools do more than a 40-page document in a shared folder - **Letting IT own everything.** IT implements; business owners decide - **Ignoring spreadsheets and chat.** Exports in WhatsApp groups and personal drives are often where restricted data actually leaks - **Treating governance as a one-time project.** Without recurring reviews, access and definitions drift back to where they started ## How Weaveward can build this for you We would start with a short assessment of your main systems, such as your accounting software, POS or ERP, CRM and marketplace exports, to map where critical and personal data lives and to draft the owner and access matrix with your managers. The first delivery would be a governed reporting layer: a warehouse with metric definitions kept in version control, role-based and row-level access in your dashboards, and audit logs for exports and permission changes. We would validate it by reconciling dashboard figures against finance's closing numbers and by testing real scenarios, such as a branch manager's view and an employee's last day. See how we approach [data analytics and dashboard projects](/services/data-analytics-dashboards), or [talk to our team](/contact) about your current setup.