# Security and data sharing with vendors

> How to judge a vendor's security evidence (SOC reports, ISO 27001, questionnaires) and control what you share, from vendor access and API keys to breaches.

Source: https://docs.lumina-erp.com/first-and-third-parties/security-and-data-sharing-with-vendors/

**In short.** Ask for independent evidence, such as a current SOC 2 Type 2 report or ISO 27001 certificate whose scope covers the service you are buying, read for exceptions and for the controls you must run yourself. Then share the least data and the least access that does the job, give every vendor its own expiring MFA-protected accounts and keys and know in advance what you will do when a vendor reports a breach.

To judge a vendor's security, ask for independent evidence, such as a SOC 2 Type 2 report or an ISO/IEC 27001 certificate. Check that its scope covers the service you are buying, its period is recent and you understand its exceptions and the controls it expects you to run. Then limit what you give the vendor: the least data, the least access, separate accounts with multi-factor authentication, keys you can rotate and a plan for the day the vendor calls to say it had a breach.

:::caution[Not legal or security advice for your situation]
Privacy and security laws differ by state, country and industry, and your customer contracts may add duties of their own. Use this page to prepare good questions, then involve counsel and a qualified security professional before you rely on any conclusion.
:::

## What each kind of evidence tells you

The table compares the evidence a vendor can offer and the limits of each.

| Evidence | Produced by | What it tells you | Limits |
|---|---|---|---|
| SOC 1 report | A CPA firm, under AICPA standards | Controls at the vendor that matter to your financial statements (for example a payroll or billing service) | Whether security in general is good |
| SOC 2 report | A CPA firm, under AICPA standards | Controls over security and, if chosen, availability, processing integrity, confidentiality and privacy | Anything outside the stated system and scope |
| SOC 3 report | A CPA firm | A short, public summary of a SOC 2 opinion | The detail you need: no control list, no test results, no exceptions |
| ISO/IEC 27001 certificate | An accredited certification body | The vendor runs an information security management system that was audited against the standard, for the scope printed on the certificate | How well any individual control worked in practice |
| Security questionnaire (SIG, CAIQ or your own) | The vendor, about itself | The vendor's own description of its controls | Independent verification, since answers are self-reported |
| Penetration test summary | A testing firm hired by the vendor | That someone tried to break in recently and what was fixed | Coverage beyond what was tested |
| Security rating or scan | A ratings service, from outside | What the vendor's internet-facing systems look like from outside | Anything inside |

## SOC 1, SOC 2 and SOC 3, Type 1 and Type 2

The AICPA defines the System and Organization Controls (SOC) family of reports, which CPA firms issue about a service organization's controls. The two questions to ask are which report and which type.

| | Type 1 | Type 2 |
|---|---|---|
| What the auditor checks | Whether controls are suitably designed at a single point in time | Whether controls are designed and operated effectively over a period, usually 6 to 12 months |
| What it proves | The vendor has the right controls on paper on one day | The controls worked, day after day, when tested |
| When it is acceptable | A new vendor's first report, with a Type 2 promised | The normal expectation for a tier 1 or tier 2 vendor |

For most software, hosting and managed IT vendors, ask for a **SOC 2 Type 2**. Ask for a SOC 1 Type 2 as well when the service feeds your financial reporting (payroll, payment processing, a hosted ERP your auditors rely on), because your external auditor may want it. A SOC 3 is fine for a marketing page but not for due diligence.

SOC 2 and SOC 1 reports are restricted-use documents. Vendors usually share them under an NDA or through a trust portal, and that is normal practice.

## How to read a SOC 2 report in 30 minutes

You do not need to read every page. Go straight to these sections, in this order.

1. **The opinion letter.** Look for an unqualified opinion (sometimes called clean). A qualified, adverse or disclaimed opinion means the auditor found something serious enough to say so up front. Read why.
2. **The system description and scope.** Confirm the report covers the product and the locations you will use. A report on the vendor's corporate IT does not cover the hosted product, and a report on one product does not cover another from the same company.
3. **The period.** Note the start and end dates. If the period ended more than about three months ago, ask for a bridge letter (next step). If it ended more than a year ago, ask when the next report is due.
4. **The trust services criteria covered.** Security is always included. Check whether availability, confidentiality, processing integrity or privacy are in scope if they matter to you. An uptime-critical service without availability in scope is worth a question.
5. **Exceptions in the test results.** Search for the word exception, or deviation. Each one shows a control that failed at least once in testing. Read the vendor's response to each and decide whether it touches your data or your service.
6. **Complementary user entity controls (CUECs).** This is the list of controls the vendor assumes you run, such as removing your own users when they leave, protecting your passwords and reviewing access. If you do not run them, the report's assurance does not fully apply to you. Copy them into your own control list.
7. **Subservice organizations.** Check which other providers the vendor relies on (often its cloud host) and how the report treats them: carve-out or inclusive (next section).

### Carve-out and inclusive methods

A report treats subservice providers in one of two ways.

| Method | What it means | What you do |
|---|---|---|
| Carve-out | The subservice organization's controls are excluded from the report. The vendor lists what it expects that provider to do (complementary subservice organization controls) | Ask for, or look up, the subservice provider's own SOC report, and confirm the vendor monitors it |
| Inclusive | The subservice organization's relevant controls are described and tested inside this report | Less work for you, but check that the included provider covers the locations you use |

Carve-out is far more common, especially for large cloud platforms. That is not a problem by itself. It means the assurance about hosting comes from a different report.

### Bridge letters

A bridge letter (sometimes called a gap letter) is a short statement from the vendor's management, not from the auditor, saying that no material changes to controls happened between the end of the report period and a recent date. It is useful to cover a gap of a few months. It is not audited, so treat it as a representation, and do not accept a chain of bridge letters instead of a new report.

## ISO/IEC 27001 certificates: read the scope statement

An ISO/IEC 27001 certificate says an accredited body audited the vendor's information security management system. The value is almost entirely in three lines printed on the certificate.

| Line | What to check |
|---|---|
| Scope statement | Names the services, products, sites or business units covered. It must include the service you are buying |
| Issue and expiry dates | Certificates run on a three-year cycle with yearly surveillance audits. An expired certificate is not current evidence |
| Issuing body and accreditation | The certificate should come from a certification body that is itself accredited. You can usually verify the certificate with the issuer directly |

Also ask for the statement of applicability summary if the vendor will share it. It lists which controls the vendor chose to apply and why some were excluded.

## Security questionnaires without the pain

When a vendor has no SOC 2 or ISO certificate, or when you need detail those do not cover, a questionnaire fills the gap. The table describes the two widely used public frameworks.

| Questionnaire | Who maintains it | What it is |
|---|---|---|
| SIG (Standardized Information Gathering) | Shared Assessments | A large licensed question set covering many risk areas, in shorter and longer versions |
| CAIQ (Consensus Assessment Initiative Questionnaire) | Cloud Security Alliance | A questionnaire for cloud providers, mapped to the CSA Cloud Controls Matrix |

Many vendors keep a completed SIG ready to share, and cloud providers can publish completed CAIQ answers in the CSA STAR registry. For a mid-sized company, a few rules keep questionnaires useful:

- Accept the vendor's existing completed SIG or CAIQ before sending your own. You get answers faster, and the vendor is more likely to be accurate.
- Keep your own questionnaire short. 20 to 40 questions that you will read beat 300 that nobody will. Focus on the areas in the checklist below.
- Ask for evidence on the answers that matter. For tier 1 vendors, a yes to MFA should come with a screenshot or policy extract.
- Scale by tier. Tier 3 vendors get a one-page form instead of a questionnaire. See [third-party risk management](/first-and-third-parties/third-party-risk-management/) for tiering.

## Give vendors the least access and the least data

Evidence tells you how the vendor protects itself. The rest of the risk sits in what you hand over. Most incidents involving vendors at mid-sized companies come through access: a shared support login, an always-on remote tool, an API key that never changes.

### Accounts and access

The table sets the standard for vendor accounts.

| Practice | Standard |
|---|---|
| One account per person | Every vendor staff member who logs in has a named account. No shared vendor logins, ever |
| Least privilege | Vendor roles grant only what the task needs. A report writer does not need to post journal entries. See [security roles and access reviews](/erp-projects/security-roles-and-access-reviews/) |
| Expiry by default | Project and support accounts have an end date. Access is re-approved, not left running |
| Named sponsor | Each vendor account has an internal owner who confirms it is still needed at each review |
| Logging | Vendor sessions and admin actions are logged somewhere the vendor cannot erase |
| Offboarding | Removing vendor access is a step in contract termination and in every vendor staff change |

### Remote access and MFA

Every remote path a vendor uses should meet these standards.

| Practice | Standard |
|---|---|
| MFA on every external path | VPN, remote desktop gateways, cloud consoles and vendor portals all require multi-factor authentication |
| On-demand remote support | Remote support tools are started by your staff for a session, not installed as always-on unattended access |
| No direct internet exposure | Remote desktop and database ports are not open to the internet for vendor convenience |
| Session approval | For production systems, someone on your side approves the session and knows what is being done |
| Separate admin accounts | Vendor admin work uses an admin account that is not used for email or browsing |

### API keys and service accounts

Integrations (EDI, e-commerce, tax, shipping, payment) usually connect with an API key or a service account instead of a person. These are easy to forget and often have more access than any human user.

- [ ] **One credential per integration.** If one leaks, you revoke it without breaking every other connection.
- [ ] **Scoped permissions.** The tax service's key reads orders and writes tax lines. It cannot read customer credit data or post to the ledger.
- [ ] **Stored in a secrets manager, not in email or a shared spreadsheet.** Credentials pasted in tickets and chats are found years later.
- [ ] **Rotation schedule.** Rotate keys on a schedule and immediately when a vendor employee with access leaves or the vendor reports an incident.
- [ ] **Interactive login blocked.** Service accounts cannot sign in to a desktop or the ERP client.
- [ ] **Owner and purpose recorded.** Every service account has a named internal owner and a one-line description in your inventory.

### Data minimization

Share the smallest set of data the vendor needs, for the shortest time.

| Instead of | Share |
|---|---|
| A full copy of the production database for a report developer | A test copy with customer names, contacts and bank details masked |
| The full customer master to a marketing tool | Only the fields and customers the campaign needs |
| Full card numbers anywhere | Tokens from the payment processor (your ERP should not store full card numbers) |
| Open-ended retention | A contract clause requiring deletion at the end of the task, with written confirmation |
| Email attachments of exports | A secure file transfer location that expires |

## Privacy and service provider rules you may be under

Several laws make you responsible for how your vendors handle personal information. Which ones apply depends on what you do and whose data you hold, and the details are for counsel. The table summarizes the main rules.

| Rule | Who it reaches | What it expects |
|---|---|---|
| FTC Safeguards Rule, 16 CFR Part 314 | Businesses that are financial institutions under the Gramm-Leach-Bliley Act, which the FTC reads broadly by activity | Under section 314.4(f), take reasonable steps to select capable service providers, require safeguards by contract and periodically assess them based on risk |
| GDPR Article 28 | Processing personal data of people in the EU on behalf of a controller | A written contract with set terms, and sub-processors only with the controller's authorization and on the same obligations |
| California CCPA regulations | Businesses in scope of the CCPA that share personal information with service providers or contractors | Contracts with specific required terms that limit how the provider may use the data |
| HIPAA business associate rules | Covered health entities and their business associates | A business associate agreement before protected health information is shared |

:::note[Is a distributor under the Safeguards Rule?]
Most distributors are not financial institutions in the ordinary sense. But the FTC rule turns on activity, not industry label, and some consumer-facing credit or financing activities can bring a business into scope. The FTC guide lists examples and a partial exemption for institutions that hold information on fewer than 5,000 consumers (FTC, retrieved 2026-09-28). If you extend credit or financing to consumers, ask counsel whether it reaches you.
:::

## When a vendor has a breach

Vendor breaches are common enough that you should decide your response before one happens. NIST CSF 2.0 asks that relevant suppliers be part of incident planning, response and recovery (outcome GV.SC-08).

### Before it happens

- [ ] **Breach notice clause.** Contracts with tier 1 and tier 2 vendors require notice of incidents affecting your data or service within a set number of hours or days, with a named contact.
- [ ] **Contact list.** You hold a 24-hour security contact for each tier 1 vendor, and they hold yours.
- [ ] **Data map.** You know which data each vendor holds, so you can tell quickly whether a breach touches customers, employees or payment details.
- [ ] **Kill switch.** You know how to disable each vendor's access and integration quickly without taking down unrelated systems.

### When the call comes

1. Get the facts in writing: what happened, when it started, when it was contained, what systems and data are affected and whether your data or your access paths are involved.
2. Cut or narrow access. Disable the vendor's accounts, VPN, remote tools and integrations into your environment until you understand the scope. Rotate every key and password the vendor held.
3. Check your side by reviewing logs for activity from vendor accounts and integrations over the affected period.
4. Bring in counsel early. Notification duties to customers, employees and regulators depend on the data and the jurisdictions involved, and some have short deadlines.
5. Tell your insurer. Cyber policies often require prompt notice and may provide response services.
6. Decide on the relationship. After the incident, review the vendor's root cause report and remediation, then decide whether to continue, add conditions or start an exit.

## Questions to ask a vendor

- Can you share your most recent SOC 2 Type 2 report, and does its scope include the product and region we will use?
- What exceptions were noted, and what have you done about them?
- Which subservice organizations do you rely on, and were they carved out?
- Which complementary user entity controls do you expect us to operate?
- How do your staff access our systems or our data, and is MFA enforced on every path?
- How do you store and rotate the credentials we give you?
- Where is our data stored, who can see it and how is it deleted when we leave?
- How quickly will you notify us of an incident, and who will call us?
- Have you had a reportable security incident in the last three years? What changed after it?

## Red flags

Any of these during due diligence or renewal deserves a follow-up question.

| Red flag | Why it matters |
|---|---|
| Offers only a SOC 3 or a marketing trust page for a tier 1 service | No detail, no exceptions, nothing you can rely on |
| SOC 2 scope does not include the product you are buying | The report is about something else |
| Report period ended more than a year ago, or a chain of bridge letters | Evidence is stale |
| ISO certificate scope covers only a head office or a single site | The service you buy may not be in the management system |
| Insists on a shared login or permanent unattended remote access | Uncontrolled, unattributable access into your systems |
| Asks for a full production data copy for a small task | More data than the job needs, held outside your control |
| Will not commit to a breach notification timeframe | You may learn about a breach from the news |
| Long list of exceptions with no management response | Controls failed and nobody owns fixing them |

## Security and data sharing checklist

- [ ] **Tier assigned.** The vendor has a criticality tier that sets how much evidence you need.
- [ ] **Independent evidence on file.** A SOC 2 Type 2 or ISO/IEC 27001 certificate for tier 1 and tier 2, dated within the last 12 months.
- [ ] **Scope confirmed.** The report or certificate covers the product, locations and trust services criteria that matter to you.
- [ ] **Exceptions reviewed.** Each exception is read and judged, with any concern raised with the vendor.
- [ ] **CUECs copied into your controls.** Someone on your side owns each control the vendor expects you to run.
- [ ] **Subservice providers identified.** Carved-out providers are known and have their own evidence.
- [ ] **Questionnaire done where evidence is thin.** Vendor's existing SIG or CAIQ accepted, or your short questionnaire answered.
- [ ] **Named, least-privilege accounts.** No shared vendor logins, and roles match the task.
- [ ] **MFA on every remote path.** VPN, remote support, cloud consoles and portals.
- [ ] **Remote support on demand only.** No always-on unattended access to production.
- [ ] **API keys scoped, stored and rotated.** One per integration, in a secrets manager, with a rotation date.
- [ ] **Data minimized.** Masked test copies, limited fields, deletion at the end of the task.
- [ ] **Contract covers security.** Security duties, breach notice timeframe, audit or evidence rights, data return and deletion.
- [ ] **Applicable privacy rules checked with counsel.** Safeguards Rule, GDPR, CCPA or HIPAA terms in place where they apply.
- [ ] **Incident contacts exchanged.** Both sides know who to call at any hour.
- [ ] **Offboarding step ready.** Access removal and key rotation are part of termination.

## Next steps

Pick your tier 1 vendors and do three things this month: collect a current SOC 2 Type 2 or ISO certificate from each, remove every shared or unused vendor account and turn on MFA for every remote path a vendor uses. Those three steps close most of the gap for most mid-sized companies. Then work through the checklist for tier 2 at each renewal.

## Sources

- [System and Organization Controls: SOC Suite of Services (AICPA & CIMA)](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services)
- [STAR Level 1: Security Questionnaire (CAIQ v4) (Cloud Security Alliance)](https://cloudsecurityalliance.org/artifacts/star-level-1-security-questionnaire-caiq-v4)
- [16 CFR Part 314, Standards for Safeguarding Customer Information (eCFR)](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314)
- [FTC Safeguards Rule: What Your Business Needs to Know (Federal Trade Commission)](https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know)
- [Regulation (EU) 2016/679 (GDPR), Article 28 Processor (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
- [CCPA Regulations (California Privacy Protection Agency)](https://cppa.ca.gov/regulations/)
- [The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 26, 2024)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf)
- [SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (NIST)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

---

Epicor, Prophet 21, P21 and DynaChange are trademarks or registered trademarks of Epicor Software Corporation registered in the United States and other countries. Kinetic is a trademark of Epicor Software Corporation. Lumina ERP is an independent consultancy and is not affiliated with, sponsored by or endorsed by Epicor.