Data security & governance.

Sensitive information moves through applications, warehouses, shared files, exports, integrations, and AI workflows. Each copy can have different permissions, retention settings, and owners.

Broadwing identifies where sensitive data lives, who can access it, and where it can leave your systems. We work with data owners to classify information, enforce access and retention rules, restrict sharing, and record data access in the systems that handle it.

An access policy only protects a dataset when the applications, service accounts, connectors, and downstream copies follow it. A retention rule only works when the team knows where the information is stored and which systems can remove it.

We work with your data, security, and application teams to find where those rules break down, assign owners, and implement fixes.

Our experience includes database and warehouse environments on AWS and Google Cloud (GCP), along with MySQL, PostgreSQL, ClickHouse, and DuckDB.

Controls depend on how the platform runs. For managed services and database servers, review cloud identities, database roles, network access, and exports. For embedded DuckDB workflows, review the host application's authorization, process isolation, file and network access, extensions, and available credentials.

Data discovery, classification, and ownership

Identify relevant data stores and flows, including operational applications, analytical platforms, object storage, shared files, and connected services. Establish which information is sensitive, how it is used, and who owns the decisions around it.

For each sensitive-data class, record its locations, owner, dependent teams, permitted uses, and handling rules. Use that classification to configure access and sharing restrictions where the platform supports them.

Identity and access

Review access through users, groups, service accounts, workload identities, and integrations. Check what each identity can actually read, export, or modify, including broad privileges, shared accounts, and access that is no longer needed.

We help restrict access to what each user or automated process needs, improve authentication and credential handling, and establish access reviews with owners who can approve or remove permissions.

Data flows, copies, and retention

Trace how information moves between source systems, pipelines, warehouses, reports, and external services. Include derived datasets and exports where they affect exposure.

Data lineage maps those source-to-copy relationships. We use it to identify which downstream datasets and exports need access restrictions or deletion when a source's rules change. We document retention and deletion dependencies, including copies the source system cannot remove directly.

Leakage controls and auditability

Review downloads, exports, connectors, outbound application traffic, and external AI services for paths that could disclose sensitive data. Apply the controls the environment supports: scoped permissions, sharing restrictions, policy checks, and data-loss-prevention (DLP) integrations.

Establish useful audit records around access, export, and permission changes. Define what should trigger investigation or escalation, and connect those signals to the people responsible for acting on them.

Data access through AI

An AI interface can make existing data easier to reach. That makes authorization at retrieval and connected-tool boundaries especially important.

We check whether the initiating user's permissions carry through to document retrieval, vector indexes, and downstream services. Source restrictions must apply to indexed copies and retrieved chunks before they enter the model's context. We also examine how permission changes and deletions reach the retrieval system.

We also review the data that enters prompts, tool calls, provider services, and logs. Those are additional handling paths with their own access and retention requirements.

The agreed scope can include:

• An inventory of relevant sensitive-data stores and flows, with identified owners.
• A classification and access matrix linking data classes to permitted users, service identities, uses, and handling rules.
• A prioritized remediation backlog with control gaps, owners, and validation criteria.
• Implemented changes to identity, permissions, connectors, retention workflows, or monitoring.
• Validation results and operating guidance for access reviews, data handling, and escalation.

Start with a defined platform, data class, or workflow. We identify downstream dependencies and agree on any scope changes with your team.

1. Map the exposure. Identify the relevant data, identities, systems, and downstream flows.
2. Agree on the rules. Work with data owners to establish authorized use, access, handling, and retention requirements.
3. Implement the controls. Make changes in the systems that store, retrieve, move, and expose the information.
4. Validate and hand over. Test permitted and prohibited access, document results, and assign recurring reviews and monitoring to named owners.

Validation follows the agreed rules. For example, can a permitted user still open a report while a removed user is denied? Does an export keep the required restrictions? Does an AI retrieval request exclude a document the user is no longer allowed to read?

For a global technology company, Broadwing modernized federated authentication between an identity provider and cloud analytics services as part of a phased analytics migration. The engagement addressed SAML authentication challenges and moved analytics environments, reports, and dashboards with no major incidents.

This is an example of the identity and platform engineering needed to change how teams access data.

Read the analytics-migration case study →

How is this different from data engineering?

Data engineering builds the pipelines and platforms that make information useful. This service focuses on who can use that information, where it can move, how it is handled, and how those decisions are enforced. The work often involves the same systems and teams.

Do we need a complete data catalog before starting?

No. We can start with one system, sensitive-data class, or business workflow. Discovery identifies its owners, access rules, and downstream copies so the team can prioritize control changes.

Does data governance include detection and alerts?

It can. We identify which access, export, or permission-change events need investigation, configure the supported logging and alerts, and name the response owners. Ongoing monitoring and response can be scoped through Continuous security & compliance.

Can we use our existing identity and data platforms?

We examine your platforms' access, sharing, retention, and logging controls. Then we identify what can be configured, what needs engineering, and which gaps depend on platform limitations.

Tell us which information matters, where it lives, and where access or visibility is unclear. We will review the fit and scope a data-security review and any remediation work with you.

Discuss a data-security review →

Select Security on the contact form and mention data security or governance. Describe the relevant platforms, data types, and access concerns.

Related: AI & agent security · Continuous security & compliance · Data engineering · Security engineering