Keep PHI out of Gruv
Gruv does not offer a Business Associate Agreement. Do not enter or upload protected health information in product fields, files, or support messages.
Sensitive-data boundaries
Know where sensitive data belongs before you launch
Keep clinical information and raw card details in the systems designed to handle them. Use this page to plan what enters Gruv, what stays with the payment provider, and what your team should share during procurement or support.
Use the approved card entry point
Payment-card responsibilities depend on the exact checkout, payout, provider, and integration path. Never paste a full card number or security code into notes, uploads, or support messages.
Map the data path before launch
Confirm what a user enters, which system receives it, what Gruv stores, and which references return from the payment provider.
Share the right context
Give teams enough to review without sending the sensitive record
Procurement and support usually need the shape of the workflow, not the live clinical or card data inside it. Redact examples before sharing them and use provider references wherever possible.
Keep out of Gruv
- Protected health information, including clinical notes, claims, diagnoses, treatment details, or patient identifiers
- Full payment-card numbers, CVV or CVC values, PIN data, or magnetic-stripe data in notes, files, or support requests
- Screenshots, PDFs, exports, or test fixtures that contain live PHI or raw card details
- Production credentials, signing secrets, or access tokens shared as ordinary support context
Useful review context
- A high-level description of the billing, payout, or contractor workflow
- A field-level data inventory that names data categories without including live values
- A fully redacted example with PHI, card details, credentials, and personal identifiers removed
- A vendor questionnaire or architecture diagram with no sensitive records attached
- Provider tokens, statuses, and references returned by an approved integration instead of raw card details
Payment-card planning
Trace the card path before you approve the workflow
PCI DSS scope is determined by the systems that store, process, transmit, or can affect the security of cardholder data. A provider logo alone does not answer that question.
- 1Where does the customer enter card details?
- 2Which systems can store, process, transmit, or affect that card-data environment?
- 3Does Gruv receive a token and status reference, or any raw card fields?
- 4Which provider account, checkout method, and support process are enabled for this workflow?
- 5Who owns PCI validation, evidence, and incident response for the final setup?
Common questions
Can we use Gruv for a workflow that contains PHI?
No. Gruv does not offer a Business Associate Agreement, so PHI must remain outside Gruv product fields, attachments, and support channels. A healthcare company can evaluate a workflow only when the data sent to Gruv excludes PHI.
Does this page claim that Gruv is PCI-DSS certified?
No. PCI scope depends on the exact card entry point, provider integration, and systems that can affect the card-data environment. Confirm that path before launch instead of relying on a generic platform statement.
Can we send card details to support for troubleshooting?
Do not send full card numbers, security codes, PIN data, or screenshots containing them. Share the provider reference, status, timestamp, and a redacted view instead.
What should we bring to a trust review?
Bring the proposed data flow, field inventory, payment entry point, provider setup, files or screenshots users may upload, support path, and the people responsible for security and procurement.