A short, scannable summary for the people who review vendors. It describes what the product does today — not planned work, and not certifications the product has not been through. The detailed Security Overview goes further and is available on request.
The data boundary
Partner Success Pulse is designed for account-level operational information and is not intended to create, receive, maintain, or transmit PHI. Customers are instructed not to enter PHI or patient information. We do not currently offer the product under a BAA.
It is not an EHR, not a clinical system, and not a patient-facing application. The workflow operates on organisations, sites, assigned staff, operational status and commercial context. There is no patient record, no clinical data type and no field intended to hold patient information anywhere in the product.
Separation and access
Each customer organisation is a separate tenant and a user belongs to exactly one. For customer roles, the tenant used by a request is resolved server-side from the authenticated session rather than accepted from a customer-supplied tenant identifier. Vendor-side administration is separate.
Four roles exist inside a tenant, enforced per role on the server rather than by hiding buttons. Sales users receive a separately constructed account record built from an explicit allowlist of fields. Internal health status, service-level exceptions, sentiment, risk level, escalations and leadership notes are not fields on that record at all, and the internal leadership surfaces — including the weekly Brief — are refused for the Sales role at the server.
Invite-only, with self-service signup disabled and no public registration route. New passwords must be at least 15 characters and are stored hashed. Sessions use a configured eight-hour lifetime with activity-based renewal and session state is read on every authenticated request, so deactivating a user takes effect on their next request rather than when a token expires. Tenant suspension blocks every authenticated request for users in that tenant, and access can optionally be restricted by IP or country.
Audit and history
Administrative actions — inviting a user, changing a role, deactivating or reactivating an account, creating or removing an organisation record — are written to an audit trail recording who acted, what action, on what target, for which tenant, and when. No application path edits an audit entry or deletes an individual entry; the application exposes the trail for reading only. Audit records are removed only when an entire tenant is deleted.
Weekly leadership history is captured as a point-in-time snapshot written inside a single transaction, and a week becomes available as a historical report only when its record count is provably complete — a partial capture is never offered. No application path rewrites a snapshot after it is written, so a historical brief shows what was true at the close of that week. Snapshots are removed only when the tenant they belong to is deleted.
Infrastructure
The application is built for and deployed to Vercel. Customer data is stored in a hosted PostgreSQL service; we currently use Neon. The application is served over HTTPS and instructs browsers to require it. Encryption of the database connection and encryption at rest are provider-configured, and we confirm current settings with the provider rather than claiming them here.
Success Layer is a U.S.-based business. That is a statement about the company, not a guarantee about where data is hosted. We do not offer a data-residency guarantee today. If region is a requirement for you, ask and we will confirm the current configuration with the provider before you rely on it.
What we do not claim
We would rather be trusted on a short list than doubted on a long one. As of today, Partner Success Pulse has not been through, and we do not claim: HIPAA status of any kind, and we do not currently offer the product under a Business Associate Agreement; SOC 2; HITRUST; or a completed third-party penetration test.
The full Security Overview separates what the application enforces itself, what belongs to our hosting providers, what is operating practice rather than code, and what we do not have. It names further current-state limitations beyond those above. It is available on request — email security@getsuccesslayer.com, or ask in your first conversation with us. You do not need to sign anything to read it.
Service information: Supplemental Terms of Service · Subprocessors · Vulnerability Disclosure Policy.
Reporting a security concern. Email security@getsuccesslayer.com. Please describe the problem without including patient information in the report itself, and tell us how to reach you if we need to ask a follow-up question.