Security & IT Questions

We understand that new tools often require review by IT, security, and data governance teams before adoption. Below are the most common questions we receive, answered directly and specifically.

What does MyDataWork actually do?

MyDataWork is a workspace for data analysts, BI developers, data engineers, and data scientists to catalog their files, document use cases, track outcomes, and visualize relationships between data assets. It is an organizational and productivity tool — not a data processing or transformation platform. It does not query, transform, or move data within your systems.

What data does MyDataWork access or store?

MyDataWork stores only structural metadata — never the data values inside your tables or the underlying contents of your data files. The metadata captured falls into three layers.

Filesystem metadata (what the operating system already exposes): file names, file paths, file types and tool classifications (Excel, SQL, Python, Jupyter notebooks, Alteryx, Tableau, Power BI, CSV, ThoughtSpot, Dataiku project exports, Looker LookML), file sizes, file creation dates, and last-modified dates.

Shallow structural metadata (extracted from a file’s structure, never its values): for SQL scripts, the table names referenced in FROM/JOIN clauses; for Excel files, sheet names; for CSV files, column names; for Jupyter notebooks, embedded SQL; for Alteryx workflows (.yxmd / .yxwz / .yxmc), the input and output files and tables, the tool and ML-model inventory, and join keys; for ThoughtSpot .tml, object kind and referenced tables; for Dataiku project exports, project name, recipe/dataset counts, and dataset table references; for Looker .lkml, dimensions, measures, and sql_table_name references. Data values, formula contents, and cell contents are never read. The structural metadata is what powers the lineage map and the “Not in catalog” external-dependency badges. The asset detail panel surfaces this extracted structure (for example table references, sheet names, recipe/dataset counts) read-only — it never displays cell values.

User-entered content: tags, notes, use case descriptions, objectives, progress measurements, stakeholder information, optional notes URLs (HTTPS links to external documentation), and analyst-defined relationships.

For locally-scanned files the metadata is extracted on the user’s own machine and only the metadata leaves the machine. For cloud sources, file source content, warehouse INFORMATION_SCHEMA, or read-only BI metadata is fetched briefly, parsed in-process to extract structure, and discarded — only the resulting structural metadata is persisted in the workspace. See “Does MyDataWork connect to our databases, data warehouse, or BI tools?” below for the per-connector breakdown.

The local Windows Connector indexes the file-level and shallow-structural metadata listed above on your machine; no file content ever leaves your computer. Cloud source connectors work differently — see the question below for what they fetch and what they retain. When AI features are used, MyDataWork sends a subset of the stored structural metadata (use case descriptions, objectives, progress notes, asset names and types, detected data source references) — never file contents — to OpenAI’s API for analysis. The desktop Connector is code-signed by MyDataWork™, LLC through Azure Trusted Signing, a public Microsoft certificate authority, so Windows verifies the publisher’s identity at install time.

Where is data stored?

All workspace data is stored in a managed PostgreSQL database (AWS RDS) hosted in the United States (us-east-1 / Northern Virginia region). The database runs in a Multi-AZ configuration with a synchronous standby in a second Availability Zone, is encrypted at rest using AWS KMS, has automated daily backups with 7-day retention and point-in-time recovery, and is not publicly accessible from the internet — connections are accepted only from within the application VPC.

How does MyDataWork handle personally identifiable information (PII)?

MyDataWork minimizes the personal data it holds and isolates it from your business data.

There are three categories, all user-entered:

Account and user identity: each user’s name and email, and a bcrypt-hashed password. Authentication uses short-lived JWTs. Card data is never stored — Stripe processes all payments.
Team member identity: when a Team admin adds a member, they enter the member’s name, email, and a starter password the member changes on first login.
Stakeholder and contact details: names, and optionally emails, a user records against a use case, plus any HTTPS notes URLs.

The core boundary: PII inside your business data is never ingested. Connectors and the Windows Connector read structural metadata only — names, paths, schema, table/column identifiers, dependency references — never file contents, cell values, table rows, or query results. Personal data sitting inside your spreadsheets, tables, or notebooks is never read, transmitted, or stored.

Subprocessors that touch personal data:

AWS (hosting, us-east-1) — all workspace data, encrypted at rest with KMS, in transit with TLS 1.2+.
Stripe — payment processing; card data never reaches MyDataWork.
AWS SES — transactional email (registration, password reset, notifications).
OpenAI — AI features. Stakeholder names and emails are stripped before any AI call; the payload is workspace metadata (asset names and types, lineage, use-case text). What reaches the model is role labels, stakeholder presence/counts, and free-text a user authors in fields like descriptions and notes — never names or emails. File contents are never sent. AI is enabled by default for new workspaces; an admin can turn it on or off any time in Setup → AI Assist.
Jira (optional, user-configured) — when a user pushes a use case, the payload includes the stakeholder names and asset names they entered.

Hashing where identity isn’t needed: the free assessment eligibility log and the account-deletion audit log store a SHA-256 hash of the email, never the plaintext address.

Rights and control: full JSON export at any time (GDPR Article 20 portability), immediate self-service account deletion (right to erasure), data minimization by design, no sale of data, no advertising use. Data Processing Agreements are available for organizational customers.

Does MyDataWork connect to our databases, data warehouse, or BI tools?

MyDataWork does not connect to, query, or read data from your databases, data warehouses, or BI tools. It does not execute queries against your business data or access underlying data values.

MyDataWork can optionally connect to twelve cloud sources — across data warehouses (Snowflake, BigQuery, Redshift, Databricks), repositories and transformation (GitHub, dbt Cloud), BI and analytics (Power BI, Tableau, Sigma, Looker, ThoughtSpot), and data science (Dataiku) — using read-only credentials provided by the user. Every connector reads structure only — no data records, query results, rendered visuals, or user data values. The way each connector works depends on the platform:

GitHub: for each parseable file in the configured repository / branch (SQL, Python, Jupyter notebooks, Tableau workbooks, Power BI files, Alteryx workflows, ThoughtSpot TML, Dataiku project exports, Looker LookML, Excel, CSV), the connector downloads the file’s raw content via raw.githubusercontent.com, parses it in-process to extract structure (system / tool type, topic tags, FROM/JOIN-referenced table names, etc.), and discards the downloaded content. Only the extracted structural metadata is persisted in your workspace. There is a 5 MB per-file size cap on the fetch step; larger files catalog with metadata but skip the content extraction.
Databricks: for each notebook in the configured workspace, the connector calls the Workspace Export API to download the notebook’s source code (Python / SQL / Scala / R), parses it for table references the same way it would a local file, and discards the source. Only the extracted structural metadata is persisted.
dbt Cloud: for each project, the connector downloads the manifest.json artifact from the project’s latest successful run — which describes every model, source, their materialized relation name, and the dependency graph between them. The manifest itself is parsed in-process and not retained; only the per-model and per-source metadata it contains is persisted as catalog entries.
Snowflake: the connector queries INFORMATION_SCHEMA.TABLES and INFORMATION_SCHEMA.COLUMNS for catalog name, schema name, table identity, column names and types, row counts, and last-altered timestamps. No SELECT * against business tables, no data values, no query results — only the warehouse’s own schema metadata.
BigQuery: read-only access via the BigQuery metadata APIs using a service account with the Metadata Viewer role; reads dataset, table, and column structure plus freshness. The role cannot read row data — no query results or data values.
Redshift: read-only INFORMATION_SCHEMA over the Postgres wire protocol (TLS required); catalog, schema, table, and column structure plus best-effort row estimates from system views. No data records.
Power BI: a read-only Azure AD service principal calls the admin Scanner API; returns workspace, dataset, report, and dashboard names plus dataset→source lineage. No report data or rendered visuals.
Tableau: a read-only personal access token calls the Metadata API; returns workbook and datasource names plus their upstream source tables. No view data.
Sigma, Looker, ThoughtSpot: read-only metadata APIs return object names (workbooks, dashboards, looks, liveboards, worksheets) plus their source references. No underlying data.
Dataiku: a read-only DSS API key returns project, dataset, and recipe names plus dataset table references. No data values.

Across all cloud connectors, the consistent boundary is: no data records, no query results, and no user data values are read or stored. File source content and notebook source code are read briefly into the connector process for parsing, but are not persisted to the workspace. What MyDataWork retains is structural metadata only — names, paths, table identifiers, column identifiers, type names, and the inferred relationships between them.

The local Windows Connector recognizes a defined set of file types by extension — including Excel (.xlsx, .xlsm), CSV, SQL (.sql), Python (.py, .ipynb), Tableau (.twb, .twbx), Power BI (.pbix, .pbit), Alteryx (.yxmd, .yxwz, .yxmc), ThoughtSpot (.tml), Dataiku project exports (.zip), and Looker LookML (.lkml). For each, it captures filesystem metadata (name, path, size, creation and modification dates) and performs shallow structural inspection to extract schema-level references — for example, table names referenced in SQL FROM/JOIN clauses, sheet names from .xlsx, column names from .csv, dimensions/measures from .lkml. Across both the local Connector and the cloud source connectors, data values, formula contents, cell contents, table rows, and query results are never read or transmitted — only structural metadata (identifiers, types, dependency references) is extracted. This metadata is what powers the lineage map and the external-dependency flags.

Cloud source connections are optional, require explicit configuration by a workspace admin, and use only the minimum API permissions needed: GitHub read access to the configured repositories; Databricks workspace read access; dbt Cloud read access to projects, runs, and run artifacts; Snowflake SELECT on INFORMATION_SCHEMA only; BigQuery Metadata Viewer role; Redshift read-only on system catalogs; Power BI read-only admin via a service principal (Scanner API); Tableau Metadata API via a personal access token; Sigma / Looker / ThoughtSpot read-only metadata API; Dataiku read-only DSS API key. The same structural metadata is extracted regardless of whether an asset arrives via the local Connector or a cloud source, so cross-tool lineage inference (the dependency map shown in the Lineage tab) treats them uniformly.

What data is sent to AI services?

MyDataWork uses OpenAI’s API to power AI features including use case proposals, AI recommendations, automation candidate identification, marketplace data suggestions, tool migration analysis, the workspace assistant, and the Workspace Agent. When these features are used, the following information is sent to OpenAI: use case titles, descriptions, objectives, and progress notes; asset names, file types, and detected data source references; and workspace plan and configuration details. Stakeholder names and emails are stripped before any AI call — only role labels, stakeholder presence/counts, and user-authored free-text reach the model.

The Workspace Agent specifically runs only when a user clicks “Analyze” — it is not autonomous and does not run on a schedule. When activated, it evaluates the workspace against a fixed set of business rules (for example, identifying assets linked to multiple use cases or use cases without assigned stakeholders) and sends the relevant metadata to OpenAI only for the purpose of phrasing the resulting finding in natural language. The detection itself is performed by deterministic logic within MyDataWork; OpenAI is not used to make the underlying judgment about whether a finding is valid.

The MyDataWork Assistant has context about your workspace structure (assets, use cases, stakeholders, and progress) so it can answer questions specific to your work. It does not access file contents at any time.

Solution Packs and Initiatives involve no AI at all: activating a pack adds editable starter templates, and initiatives are an organizational grouping — neither sends anything to the model or consumes credits.

File contents are never sent to OpenAI or any external service. AI is enabled by default for new workspaces; an admin can turn AI features on or off any time in Setup → AI Assist. AI usage is subject to a daily quota visible in the Setup tab, and the cost of every AI action is disclosed at the point of clicking. The first Propose use cases run and up to two Workspace Agent attempts are free and do not draw from the daily AI-credit quota. If an AI call fails for any reason, the credit is automatically refunded. OpenAI’s data processing terms apply to data sent through the API.

Can external AI agents access our workspace through MyDataWork? (Agent access / MCP)

MyDataWork includes an optional feature called Agent access that lets a user expose their own workspace context to an external AI agent over the Model Context Protocol (MCP), an open standard. It is governed by the same metadata-only boundary as the rest of the product, and is designed so that MyDataWork never becomes a data-access or credential broker.

Specifically: (1) Exposure is opt-in at the use-case level — nothing is shared unless the user explicitly grants a specific use case to a specific access key. (2) Access is scoped per key — an agent sees only the use cases granted to the key it presents, and nothing else. (3) What is exposed is metadata only — asset names, tool types, structural schema (column names and types), lineage relationships, and use-case outcomes. Data values, file contents, and stakeholder names are never exposed. (4) MyDataWork provides only the “map” of where data lives (source system, schema, and table identifiers) — never credentials, and never the data itself; the agent reads any underlying data through its own connections, not through MyDataWork. (5) Every key creation, grant change, and agent read is recorded in the workspace audit log, and keys can be revoked at any time.

Access keys are bearer credentials, stored hashed at rest (never in plaintext) and presented over TLS to the hosted MCP endpoint. There are two modes: Live (on-demand reads; paid plans; metered by a daily read cap) and Export (the user downloads a point-in-time metadata file to provide to their agent out-of-band; available on all plans). On the free Explorer plan only Export mode is available. Live mode is usable only by MCP clients that authenticate with a bearer Authorization header (for example Claude Code, custom agents, or agent frameworks); clients whose connectors require OAuth — including Claude Desktop — cannot use Live mode and instead use Export, which is compatible with any agent. These limits are a separate quota from AI credits. As with every other feature, no business data values or file contents are ever read, transmitted, or stored.

How does Agent Studio handle MCP source cataloging? (metadata only, no runtime)

MyDataWork’s Agent Studio helps teams scope agentic use cases before they are built. It does not build, run, or route AI agents, and it introduces no runtime data path. Its security posture:

Metadata only, never invoked. When you catalog an MCP source, MyDataWork performs read-only capability discovery — it reads the tools, resources, and prompts a server advertises (names, descriptions, input schemas). It never calls a tool, never reads a resource, and never retrieves a data value. The discovery client hard-refuses the invoking methods (tools/call, resources/read, prompts/get, resources/subscribe) at the protocol layer, so cataloging cannot cross into execution even by mistake.
No credentials or data stored. What we keep is structural: per tool, its name, description, and input-parameter shape; per source, server name and version, protocol version, auth mode, declared capabilities, counts, and catalog timestamp. No secrets, no file contents, no data values.
AI drafting is metadata-bounded. When AI drafts the surrounding definition, only tool and source names and the labels you type are sent to the model — never data values, and never stakeholder names or other personal data. This boundary is covered by an automated PII-boundary test in our CI.
Upstream of, and complementary to, your MCP control point. Industry guidance (for example from Gartner) is to govern MCP at a runtime control point — validating sources and enforcing identity, policy, and audit before any tool is invoked. Agent Studio operates upstream of that runtime and has no runtime footprint. It is not a control point and does not attest that a server is safe. Every exported definition ends with a “Before you build” hand-off directing your team to route runtime tool access through their governed control point and validate each source (identity, allow-list, audit) before invocation. You scope with MyDataWork; your gateway governs the runtime.
Tenant isolation and least data. Cataloged MCP sources and the agentic definitions you create are scoped to your workspace and personal to their author by default. They are a separate pool from your data assets. Deleting your workspace removes them; workspace export/import round-trips them within your own tenant.

This is the reverse direction from Agent access (described above), where an agent you choose reads the structure of your cataloged data work over MCP — that capability’s metadata-only, opt-in, audited, and revocable posture is unchanged. Agent Studio catalogs the tools your systems expose, so you can design with them.

Is the Asset Estate Assessment handled differently from other AI features?

The Asset Estate Assessment is an AI-powered review of the workspace, runnable on demand. The first run is free on every plan; you can re-run it any time afterward (subsequent runs use AI credits like other AI features). It uses OpenAI in the same way other AI features do — file contents are never sent. What’s distinct from the other AI surfaces:

What is sent to OpenAI: asset metadata (names, paths, tool types, topic tags, lineage edges) and use case text (titles, objectives, descriptions, value figures, and stakeholder roles — names and emails stripped) — never file contents. The assessment additionally sends structural observations derived from the lineage graph (cross-use-case asset concentration, external dependencies, orphan assets) and a snapshot of recent Workspace Agent findings.

Workspace-grounding filter: every finding the LLM produces is checked against the workspace’s actual assets, use cases, and stakeholders by a deterministic filter before it’s surfaced. Findings that name no specific workspace entity (template phrasings like “consolidate your KPI dashboards”) are dropped during synthesis. This is implemented in the application, not in the LLM call, so it can’t be bypassed by prompt-injection.

Eligibility tracking and the hashed-email log: the free-first-run affordance is enforced via a separate eligibility log keyed on a SHA-256 hash of the lowercased email. The plaintext email is not stored in the log — only the hash and a timestamp. This is the only place in MyDataWork where a per-email record persists across workspaces; its sole purpose is to prevent a user from re-claiming the free affordance by registering a new workspace under the same email. The hash is one-way; a security reviewer auditing this table sees timestamps and hex strings, not email addresses.

Storage of the result: each assessment run persists the rendered five-section markdown report to the workspace’s database, scoped to the workspace’s org_id. Users can revisit and re-export past assessments. The markdown is the artifact the workspace owner sees and exports; the LLM intermediate outputs are not retained.

Disabling: as with other AI features, the Assessment is gated by the AI-enabled setting in workspace settings. Disabling AI hides the Assessment card entirely.

Does the Jira integration store or transmit sensitive data?

The Jira integration stores your Jira instance URL and API token encrypted at rest in your MyDataWork workspace, using the same encryption applied to all other credentials in the system. These credentials are used only to push use case summaries to your Jira instance and are never transmitted elsewhere.

The content pushed to Jira contains only information you have explicitly entered into MyDataWork — use case titles, descriptions, objectives, progress notes, stakeholder names, and asset names. No file contents, no underlying data, and no system credentials other than the Jira token itself are involved in the integration.

The Jira integration is optional, disabled by default, and must be explicitly configured by a workspace admin in Setup → Integrations. Jira integration calls are rate-limited to 20 per hour to ensure reliable platform performance.

Does installing the Connector require admin privileges or network changes?

The Connector is a lightweight Windows desktop application. It typically does not require administrator privileges to install, does not open inbound network ports, does not modify system files, and does not require firewall rule changes. It communicates only with the MyDataWork web application over standard HTTPS (port 443), and it scans only the folders the user assigns to that account.

Does the Workspace view’s “Open file” button create any new data access?

No. The Workspace view’s Open file button asks the Windows Connector (running on the user’s own machine) to open the file in the user’s default application — the same local-open action already available on the Assets tab. Nothing is uploaded or transmitted, and MyDataWork gains no new data access; if the machine has no app for that file type, the OS shows its normal app picker. Cloud assets have no local file and instead deep-link in-app. The Workspace view is a read-only view over the existing catalog — no change to the security posture.

What network access does MyDataWork require?

Users need outbound HTTPS access to app.mydatawork.com on port 443. No VPN, no special network configuration, and no inbound connections are required. The application is fully cloud-hosted. If the optional Jira integration is configured, outbound HTTPS connections are also made to your organization’s Jira instance URL on port 443.

MyDataWork applies rate limits to certain features to ensure reliable platform performance for all users: lineage rebuilds (5 per day), Jira integration calls (20 per hour), and exports (10 per day). Rate limits are documented in the in-product help and apply to normal usage.

Can access be limited to specific users or teams?

Yes. MyDataWork supports workspace-level access control. Team plans designate a single workspace admin (Owner) who manages member access. The admin creates member accounts directly by entering each member’s name, email, and starter password — there is no email-invite flow into an existing workspace, and a user cannot self-add themselves to a workspace they have not been added to by an admin. (Individuals can self-register at app.mydatawork.com to create a new workspace of their own on the Explorer plan; they cannot self-join an existing workspace.)

Team plan tiers enforce seat limits: Team Starter supports 2 to 5 members total, Team Growth supports 6 to 10 members. Admins can remove members at any time, transfer admin ownership to another member, or delete the workspace entirely. When a member is removed, their contributions remain with the workspace under the admin’s control.

How is data isolated between members within a Team workspace?

Team workspaces use a private-by-default model. Each member has their own personal workspace within the team where their assets, use cases, initiatives, lineage, stakeholders, AI recommendations, and insights are private to them — including the workspace admin’s own work. The default view on every surface (Assets, Use Cases, Workspace Agent, Dashboard) is filtered to the assets the viewing member can see: their own, plus any asset another member has explicitly published to the team via the Share to Team action on the asset detail panel.

Per-member import attribution: assets brought in through the Windows Connector are attributed to the member who installed the Connector and imported them, and stay private to that member until they choose to share — one member’s imports never land in another member’s space, and never become visible to the team automatically.

Only assets are shareable. Use cases, initiatives, lineage, stakeholders, AI recommendations, and insights remain personal to their creator regardless of asset sharing. The person who shared an asset (or the team admin) can unshare it at any time; copies others have already made via the “Copy to mine” action are independent and unaffected.

Export scope: portfolio and use-case exports (PDF / PowerPoint) respect the same private-by-default scope — a member’s export includes only their own and shared assets, never another member’s private work. Exporting across the full workspace catalog requires the admin Workspace view.

Admin Workspace view: Team admins additionally have a Workspace tab on the Assets, Use Cases, and Workspace Agent surfaces that exposes the full workspace catalog across all members’ private content — explicitly opt-in (not the default), intended for onboarding, audit, and oversight tasks. Use of the Workspace view is logged.

No cross-tenant access: each customer organization is logically isolated at the database level using an org_id foreign key on all data tables. Cross-workspace data access is not possible through the application layer.

The Asset Health Dashboard respects the same private-by-default scope — every count and panel reflects the assets the viewing member can see, matching the default view on the Assets tab.

Can users delete their own accounts and data?

Yes. Users can delete their own accounts and all associated data from the Account section at any time. Account deletion is immediate and permanent — data is removed without the 30-day retention period that applies to subscription cancellation. For Team plan admins, ownership must be transferred to another member before deletion. All deletion events are logged for audit purposes with hashed identifiers, not full email addresses.

Subscription cancellation is a separate action that retains data for 30 days, allowing the user to resubscribe and recover access. Self-service account deletion bypasses this retention period and removes data immediately.

Can users export and take their data with them?

Yes. MyDataWork supports comprehensive data portability through multiple export options:

Full workspace export (JSON): Users can export their entire workspace as a JSON file at any time from Setup → Data portability. The export includes all assets, lineage edges, stakeholders, use cases (with objectives, progress measurements, baseline/current/target values, priorities, effort estimates, target dates, notes URLs, communication logs), saved AI recommendations, action plans, and Workspace Agent finding history. The exported JSON can be imported into any MyDataWork workspace, supporting both backup and migration use cases.

Portfolio exports: Use cases, portfolios, and lineage diagrams can be exported as PowerPoint or PDF documents directly from the application.

Subscription cancellation: Upon subscription cancellation, data is retained for 30 days to allow for export and potential resubscription before permanent deletion.

Can we use MyDataWork as part of a backup or disaster recovery strategy?

The JSON workspace export is suitable for self-managed backups. Users can export their complete workspace at any time, store the JSON file in their organization’s backup system, and restore by importing the JSON into a workspace. The import is a merge operation — existing data is updated and new data is added, but nothing is deleted — so the same JSON can be re-imported safely.

MyDataWork itself maintains operational backups of the production database — automated daily snapshots with point-in-time recovery within the retention window. The database runs in a Multi-AZ configuration with a synchronous standby in a second Availability Zone for high availability. The restore-from-snapshot procedure is documented and periodically tested. Customer-managed JSON exports provide an additional layer of independent data portability that does not depend on MyDataWork’s availability.

Do Enterprise plans change the security model?

No. Enterprise plans change commercial terms only — negotiated seat counts, higher per-organization limits (assets, AI credits, agent access), and invoice-based billing. The data handling, member isolation, connector behavior, and AI-processing posture described on this page are identical on every plan.

Is MyDataWork SOC 2 certified?

SOC 2 certification is on our roadmap. Our infrastructure runs on AWS, which maintains SOC 2, ISO 27001, PCI DSS, and other certifications. We follow defense-in-depth security practices including:

Encryption at rest (AWS KMS) for the production database and per-customer integration credentials; encryption in transit via TLS 1.2+ with enforced HTTPS.
Application secrets in AWS Secrets Manager, resolved at container start through a scoped IAM role — secrets are not stored in plaintext configuration.
Network isolation: the production database is not publicly accessible from the internet, and the application tier runs in private subnets.
High availability and backups: the database runs Multi-AZ with automated daily backups, point-in-time recovery within the retention window, and a restore procedure that is documented and periodically tested.
Continuous monitoring with alerting on application errors, database health, and infrastructure saturation.

How are user credentials protected?

Passwords are never stored in plaintext. All passwords are hashed using industry-standard bcrypt. Authentication uses short-lived JWT tokens. Users can reset passwords via email verification. We do not store payment card information; payments are processed by Stripe.

Does MyDataWork comply with GDPR or CCPA?

MyDataWork supports key rights established by GDPR and CCPA:

Right to data portability: Users can export their complete workspace as a JSON file at any time, satisfying GDPR Article 20 requirements for structured, machine-readable export.
Right to erasure: Users can delete their own accounts and all associated data via self-service deletion at any time. Deletion is immediate and permanent.
Data minimization: MyDataWork stores only the data users explicitly enter and metadata users explicitly choose to index. We do not sell user data and do not use data for advertising.

We are happy to discuss data processing agreements for organizational customers.

What happens if we want to stop using MyDataWork?

There is no lock-in. Export your complete workspace as JSON at any time, or export portfolios and use cases as PowerPoint or PDF. Cancel your subscription from Account settings — data is retained for 30 days after cancellation. For immediate, complete removal, use the self-service account deletion option in your Account section. The Connector can be uninstalled like any standard Windows application.

Who do we contact with security questions?

Email contact@mydatawork.com. We aim to respond to security-related inquiries within 2 business days.