Guide

Before Sharing a Business Data Export With a Software Partner

How to prepare and transfer a limited business data export with clear access, retention, and removal rules.

By N2N Systems7 minute read

A data export can be the quickest way to understand an existing system or test a proposed connection. It can also contain far more than the project needs, including old records, internal notes, formulas, hidden columns, and identifiers that are easy to miss.

Before sending the file, write down what the recipient needs to learn from it. Create a copy containing only the records needed for that work, then set the storage and removal rules.

Start with the question the file needs to answer

Ask the person requesting the export to describe the task they will perform with it. Mapping fields between two systems, checking whether order records can be matched, and designing a dashboard each require different data.

Record the purpose beside the request. Include the expected output, the people allowed to use the file, and the date when its usefulness should be reviewed. A new use should receive a new decision from the data owner.

Confirm that the records may be shared

The person who owns the records should classify the information before an export is created. Mark confidential business material and records about people that require closer handling. Flag anything subject to a contract, customer promise, legal hold, location restriction, or disclosure rule.

Confirm the receiving organization, approved purpose, and people who will have access. If ownership or authority is unclear, ask the responsible privacy, security, legal, compliance, or contract owner before creating the export. Hold the file until the disclosure is approved.

Reduce the export at the source

Select the fields, date range, business unit, record type, tenants, and attachments in the source system when possible. This avoids creating a broad local copy merely to remove most of it later. Keep stable source identifiers only when matching or reconciliation requires them.

If the source can produce only a full export, place it in a restricted working location covered by the source's handling rules. Keep it out of personal download folders and automatically synchronized drives. Limit who can open it, prevent unnecessary copies, and remove the staging file after the approved limited copy is checked.

Synthetic records should be newly fabricated examples that cover ordinary and difficult cases. Avoid carrying rare combinations or free-text details from real records into the examples. When real records are required, use a controlled sample and remove values the task does not need.

Replacing names with codes does not make the data anonymous. Review direct and indirect identifiers together, protect the coded file as identifiable unless re-identification has been credibly ruled out, and keep any lookup key separately under the owner's control unless the approved task requires it.

Inspect the limited copy

Inspect every part of the limited copy, including hidden sheets and document properties. Free-text notes, filenames, formulas, macros, external links, and embedded objects deserve attention because they can expose data or run active content. Scan attachments in an approved environment.

Choose a format that is safe for the recipient's actual import or viewing path. A CSV file cannot carry spreadsheet macros, although formula-like cell values may still be interpreted as commands when spreadsheet software opens it. Handle those values for the named destination rather than treating conversion alone as a safety control.

Someone who understands the source should explain fields with unclear names. Blank values may mean unknown, unavailable, or not applicable, so confirm the source system's convention. Check how the export represents deleted, corrected, canceled, and duplicate records.

Include a data note and file record

A smaller file is easier to misread when its business meaning is missing. Send a brief note with the source, export time and time zone, filters, schema or export version, and any redaction or transformation steps.

For each field, describe its meaning, format, allowed values, and treatment of blanks. Identify the source key used for matching, along with any rule for corrections or later versions. State whether totals include tax, canceled items, credits, or other adjustments that could change the interpretation.

Record the reviewed filename, row count, expected columns, and version. For files where substitution or tampering would matter, add a checksum or signed manifest. Ask the recipient to acknowledge what arrived and define how a corrected export supersedes the earlier copy.

Verify the destination and control access

Verify the requester's identity, organization, destination account, file version, and access list through a trusted channel. The private transfer service should provide the encryption, recipient authentication, logging, expiration, and revocation required for the data. Add multi-factor authentication when the service supports it and the classification calls for it.

Give access through individual managed accounts, limited to the work each person is doing. The data owner should know who can change the access list and how to revoke a link or account. Review that list during the task and remove people when their role changes. Shared accounts make those checks unreliable.

A separate password may supplement an approved encrypted package. Send it through another approved channel and test the revocation path before the transfer. Keep credentials and recovery codes out of the package. Separate approval is required before the export enters a demonstration, model-training process, product-improvement program, or unrelated support ticket.

Account for subprocessors and other tools

Before transfer, the recipient should disclose each separate service or organization that may receive the export. Include cloud storage, support and ticketing systems, analytics services, model providers, subcontractors, and the countries or regions where processing will occur.

The written arrangement should state which recipients are approved and apply the purpose, confidentiality, access, incident, retention, and removal requirements to them. It should also name who remains responsible for coordinating their access and confirming their removal of the data.

Set retention and removal before sending

Name the person responsible for the export on each side. Check for a legal hold or required retention period, then choose a review date and a removal date based on the task.

Apply the removal plan to the upload, working and derived copies, returned outputs, diagnostics, backups, and subprocessor copies. If a backup system cannot remove one file immediately, document an outside age-out date and restrict access until then. The same deletion or restriction should apply after a backup restoration.

Define the evidence needed when active copies are removed or returned. The sensitivity of the export may call for a system record, administrator report, or attestation that covers named locations and recipients. Keep that evidence with the project record without repeating sensitive field values.

Check the sample before sharing more

Have the recipient return the proposed field map, match report, prototype view, or other agreed output from the limited file. Compare it with the source and investigate missing records, unexpected joins, changed totals, stale versions, and values interpreted incorrectly.

Returned maps, screenshots, reports, and prototype views are new copies. Apply the same minimization, transfer, access, retention, and removal rules to them. Prefer counts, error categories, or redacted examples when the full source values are unnecessary.

Expand the data only when the next task requires additional records or fields. Record the limited sample's result, who approved the next increment, and the updated access and removal dates before sending more.

Prepare for a transfer incident

Record an incident contact and notification route on both sides before the file moves. The written arrangement should set the reporting window, the initial facts the recipient provides, who coordinates subprocessor notices, and how status updates continue. Use the same route for a misdirected file, exposed link, suspected unauthorized access, lost device, or other misuse.

When an incident is suspected, stop further sharing and revoke available access. Preserve only the facts needed to establish what happened, which file and recipients were involved, and which containment steps were taken. Coordinate the response with the organization's privacy, security, legal, or compliance owner so contractual and legal notification duties are evaluated by the responsible people.

Record how the exposed copy was invalidated, what subprocessors did, and who decided whether the transfer could resume.