How to Choose a Data Importer for Sensitive Customer Data

Choose a data importer for sensitive customer data on four criteria: where the file is processed, which certifications the vendor holds, which agreement they will sign, and what they retain after the import finishes. Architecture matters more than certification. An importer that processes files entirely in your user's browser never holds the data, which removes the vendor from your compliance scope rather than wrapping controls around it.

Most security reviews of a data importer start with a certification checklist. That is the wrong order. A certification tells you the vendor operates controls. It does not tell you whether your customers' data reaches the vendor at all, and that second question decides how much of the review you actually have to do.

Where is the file processed? Ask whether the file is uploaded to the vendor's servers, written to storage you control, or parsed in the end user's browser without leaving the device. This single answer determines whether the vendor is a data processor in your compliance documentation or is never in the path.

Which certifications does the vendor hold, and are they current? Ask for the certification type and the date of the most recent report. SOC 2 Type II covers a period of operation. A Type I report covers a single point in time. Ask which one you are being shown.

Which agreement will they sign? Certification is a posture. An agreement is a contract with liability attached. If you handle protected health information, the question is whether the vendor will execute a Business Associate Agreement, not whether they describe themselves as HIPAA compliant.

What do they retain after the import finishes? Ask what is stored, for how long, and whether you can configure it. If the answer is that nothing is retained because nothing was ever received, the question resolves itself.

Dromo answers the first question with Private Mode, which processes imports completely in the end user's browser, and states that by default Dromo never sees the end user's data. Dromo is SOC 2 Type II certified, is HIPAA compliant with a Business Associate Agreement available for use with PHI, and describes its GDPR posture as privacy-first architecture. The full statement is on the Dromo data privacy page.

There are three architectures in this market. They are not degrees of the same thing. They put your customers' data in three different places, with three different consequences for your compliance scope.

Vendor-hosted processing. The file uploads to the vendor's infrastructure, where it is parsed, validated and transformed, then delivered to you. This is the most common model because it is the easiest to build. The compliance consequence is that the vendor becomes a processor of your customers' data. You inherit their retention policy, their breach surface, their sub-processor list and their data residency. Every one of those becomes a question your customer's security team can ask you, and you cannot answer any of them from your own documentation.

Bring your own storage. The file is written directly into cloud storage you own, such as an S3 or GCS bucket, and the vendor operates on it there. The compliance consequence is that the data stays inside your boundary. The vendor still touches it, but it never rests in their environment. Dromo offers Bring Your Own Storage, in which Dromo is given write-only access to your cloud storage.

Browser-side processing. The file is parsed, validated and corrected inside the end user's browser, and the result is handed to your application's frontend. The file never transits the vendor's servers. The compliance consequence is the largest one: the vendor is not processing your customers' data, so most of the questions above stop applying rather than getting better answers. Dromo's Private Mode works this way.

The right choice depends on what you are importing. For a marketing contact list, vendor-hosted processing is usually fine. For protected health information, financial account data or student records, the architecture question is the whole review, and browser-side processing shortens it more than any certificate will.

Certifications are useful and frequently misread. Each one has a specific scope, and the gap between what it covers and what a buyer assumes it covers is where security reviews go wrong.

SOC 2 Type II covers the vendor's controls, not your data flow. A Type II report attests that the vendor operated its stated controls over a period of time, usually six to twelve months. It says nothing about whether your particular integration is configured well, whether your users upload data they should not, or where that data ends up in your own systems. A vendor can hold a clean SOC 2 Type II report and still be the wrong architecture for your data. Dromo is SOC 2 Type II certified.

HIPAA compliance is a posture. A BAA is the contract. There is no government body that certifies a company as HIPAA compliant. A vendor claiming HIPAA compliance is describing how they have built and documented their controls. What has legal force is the Business Associate Agreement, which makes the vendor contractually liable for safeguarding PHI. If a vendor markets to healthcare but will not sign a BAA, the marketing is doing work the contract will not. Dromo is HIPAA compliant and a BAA is available for use with PHI.

GDPR readiness is architecture plus paperwork. GDPR is not a certification at all. Compliance depends on your lawful basis for processing, your records, and your agreements with anyone who processes personal data on your behalf. A vendor can help by minimizing what they process, which is an architectural property, but they cannot make you compliant. Dromo describes its GDPR position as privacy-first architecture, on the data privacy page.

Encryption is table stakes, and the specifics matter. Ask for the cipher and the scope rather than an adjective. Dromo encrypts all data and metadata at rest with AES-256, and in transit with TLS version 1.2 or higher.

None of this makes your product compliant. A certified vendor is one input into your own compliance program. The vendor's report covers the vendor.

Certifications get discussed. Agreements are what actually get signed, and each regulation asks for a different one.

HIPAA requires a Business Associate Agreement. If a vendor creates, receives, maintains or transmits PHI on your behalf, they are a business associate and a BAA is required. Dromo offers a BAA for use with PHI. Note the architectural point: under Private Mode, where the file is processed in the end user's browser and Dromo does not see the data, the question of whether a vendor is handling PHI changes shape entirely.

GDPR requires a lawful basis and a data processing agreement. You need a documented lawful basis for processing personal data, and a DPA with each processor acting on your behalf. If a vendor never processes the data, the second requirement narrows considerably.

FERPA and COPPA apply to education data. Student records carry their own obligations, and consent requirements for children under 13 are separate again. Both are worth raising explicitly with any vendor whose product will sit in an education workflow.

Dromo also offers on-premise and self-hosted deployment, which is the option to ask about when a regulator or a customer contract requires that data cannot leave infrastructure you control. Deployment options and plan details are on the Dromo pricing page, and the architectural comparison against other vendors is on the Dromo comparison pages.

A healthcare logistics platform receives files from 23 different partner organizations. No two use the same template. Field names differ and date formats differ. Every one of those files carries protected health information.

The platform evaluated importers on the four questions above. Certifications were not the deciding factor, because more than one candidate held a current SOC 2 Type II report. The deciding factor was the first question. With vendor-hosted processing, every one of those 23 files would have transited a third party's servers, and the platform's own customers would have been entitled to ask where. That turns each new partner into a security review.

They chose browser-side processing. The file contents never reach the importer vendor's infrastructure, so the vendor does not appear as a processor of PHI in the platform's documentation. The compliance question moved from "how does the vendor protect this data" to "the vendor does not receive this data," which is a shorter conversation and a smaller ongoing obligation.

The general lesson is not that browser-side processing is always right. It is that the architecture decision constrains every compliance conversation that follows, and it is much harder to change later than a certification is to obtain.

Evaluate four things: where the file is processed, which certifications the vendor holds and how recent they are, which agreement the vendor will sign, and what they retain afterward. Architecture is the most important of these, because it determines whether the vendor is in your compliance scope at all.

Dromo is SOC 2 Type II certified, as stated on its data privacy page. When evaluating any vendor, ask for the report type and the period it covers, since a Type I report examines controls at a single point in time while Type II covers their operation over months.

Yes, though no authority certifies HIPAA compliance. What matters is whether the vendor will sign a Business Associate Agreement, which creates contractual liability for safeguarding protected health information. Dromo is HIPAA compliant and offers a BAA for use with PHI. Ask any vendor for the BAA before the certification claim.

GDPR is not a certification. A vendor supports your compliance through architecture that minimizes what they process, plus a data processing agreement covering anything they do handle. Dromo describes its approach as privacy-first architecture. Your own lawful basis and records remain your responsibility regardless of vendor.

Practices vary, so ask for the cipher rather than an adjective. Dromo encrypts all data and metadata at rest using AES-256 and in transit using TLS version 1.2 or higher. Also ask what is encrypted, since some vendors encrypt file contents but not the surrounding metadata.

The main risks are the file resting on a third party's servers, retention beyond what you expect, and personal data reaching systems that were never scoped for it. A CSV of customer records is often the most sensitive payload your product accepts, and it usually arrives through the least examined path.