The answers your security team already drafted the questions for.
Strkr is compliant with GDPR and CCPA today. HIPAA is compliant with a BAA available. SOC 2 Type II is in progress, with completion targeted for the fourth quarter of 2026. No vendor-locked subprocessors. No AI training on customer records. The rest of the page is the detail.
Where Strkr stands, right now.
Compliance in the regulation that matters most.
The General Data Protection Regulation sets the ceiling that every other modern privacy law aspires to, and Strkr is built to meet it. Every workspace has a Data Processing Agreement available with Standard Contractual Clauses that cover transfers out of the European Economic Area. The DPA is signed as part of the paid-tier onboarding flow, not as a six-week legal negotiation that stalls procurement.
Data residency inside the European Union is available on the Scale tier. Workspaces that elect EU residency have their primary database, their backups, their object storage, and their log destinations provisioned in an EU AWS region. Processing stays inside that region. Support engineers who touch the workspace do so from workstations with the same regional constraints.
The right to be forgotten is handled through the Anonymize flow. When a data subject requests deletion, workspace owners can run the Anonymize action against the record, which replaces personally identifiable fields with hashed tombstones while preserving referential integrity in the rest of the data model. The audit log records the request, the action, and the operator. The thirty-day resolution window required by GDPR Article 12 is enforced in the ticket SLA, not left to goodwill.
DPA with SCCs, signed on sign-up.
Every paid workspace signs a Data Processing Agreement that includes Standard Contractual Clauses for cross-border transfers. Procurement does not have to invent one.
EU region on Scale.
Primary database, backups, object storage, and logs all provisioned inside the European Union when a workspace elects EU residency. Support access respects the same regional constraints.
Anonymize flow, audited.
Workspace owners run the Anonymize action against a record. Personal fields are replaced with hashed tombstones. Referential integrity survives. The audit log records every step.
California, resolved.
The California Consumer Privacy Act gives California residents the right to know what personal information a business has collected about them, the right to delete it, and the right to opt out of its sale. Strkr honors all three in practice because the product does not create a conflict with any of them.
Right-to-know requests are acknowledged within ten business days and resolved within forty-five. Workspace owners run the data-export tool, which produces a structured archive of every record associated with the data subject, and deliver the archive to the requester through the channel the data subject specified. The flow is the same whether the request comes from a resident of California, Colorado, Virginia, Connecticut, or any other state with a recent privacy law.
The right to opt out of sale is a non-issue on Strkr because Strkr does not sell data. There is no advertising business model. There is no data licensing side revenue. There is no aggregated product insights deal with a third party. The business model is subscription software, and that is the entire business model.
Covered healthcare customers, covered.
Strkr is compliant with the HIPAA Security Rule for healthcare customers who sign a Business Associate Agreement with us. The BAA is available on request and is signed as part of the onboarding flow once a workspace identifies itself as a covered entity or a business associate under HIPAA. There is no additional per-seat fee and no gated feature.
The technical safeguards that the Security Rule asks about are already in place: encryption at rest through AWS KMS, encryption in flight through TLS 1.3, audit logs on every write, access controls at the role and field level, automatic logoff on idle sessions, and backup procedures with tested recovery. The administrative safeguards are documented in the policies that accompany the BAA.
Strkr does not accept protected health information from workspaces that have not signed a BAA. If a workspace that has not signed one attempts to store PHI, support will reach out to walk through the agreement. The point is to be a serious partner for the healthcare customers who need the coverage, not to pretend that every workspace is HIPAA-ready by default.
Available on request.
Business Associate Agreement available for covered entities and business associates. Signed as part of onboarding once a workspace identifies itself under HIPAA. No tier gate, no additional per-seat fee.
Technical controls already there.
KMS encryption at rest, TLS 1.3 in flight, audit logs on every write, scoped and field-level permissions, automatic session logoff, tested backup recovery.
Scoped to BAA customers.
Strkr does not accept PHI from workspaces that have not signed a BAA. Support reaches out to walk through the agreement before any PHI is stored.
In progress, honestly.
SOC 2 Type II is an attestation that a service organization has operated the controls it claims to operate, over a period of time, verified by an independent auditor. The Type II report is the one that enterprise security teams actually read, because it covers a window of months rather than a point in time.
Strkr is currently in the SOC 2 Type II audit window. The pre-audit controls are in place. The external auditor is engaged. The observation period runs through the fourth quarter of 2026, and the final report is expected to close in that quarter. We do not describe the audit as complete until the attestation letter is in hand, because an audit that is in progress is not the same thing as an audit that passed.
Prospects evaluating Strkr during the audit window can receive a letter of attestation from the auditor describing the stage of the engagement, under NDA. Once the Type II report closes, the report is available to customers and qualified prospects on request, also under NDA. We are deliberate about the status language because the industry has a tolerance for ambiguity on this topic that we do not share.
The decisions that should be obvious.
Your data stays yours.
Strkr does not aggregate customer records for 'product insights.' Strkr does not sell anonymized data. Strkr does not license datasets to partners. The business model is subscription software.
Your records do not train models.
Strkr AI calls out to Bedrock for inference on behalf of a specific workspace. No customer data is used to train, fine-tune, or improve any model, ours or a vendor's. The prompts and responses are not retained outside the invocation audit log.
Strkr staff cannot see your data.
Support access requires a per-incident grant from a workspace owner. Every access is logged, time-bounded, and visible to workspace owners in the audit log. There is no god-mode and no shadow admin.
A permanent record of what changed.
Every write operation produces an audit entry: who, what, when, from where, with the before and after of the field. Retained for twelve months on Team and twenty-four months on Scale. Exportable to a workspace-owned destination for longer retention.
Where your data actually goes.
A subprocessor is a third party that processes customer data on behalf of a service provider. Honest disclosure of the subprocessor list is a GDPR requirement and a procurement question that most SaaS vendors answer vaguely. Strkr publishes the full list, with the purpose of each engagement and the type of data each one touches.
The list is kept current. Workspaces can subscribe to subprocessor change notifications, which are sent thirty days before a new subprocessor is onboarded, with the opportunity to object before the change takes effect. The notification is a product feature, not a policy document that lives on a page nobody reads.
The identity surface, in detail.
Strkr's identity surface is designed to be the surface a security team already expects, not a bespoke permission model that requires a certification to understand. Users authenticate through Clerk. Roles and permissions are scoped at the workspace. Access is granted at the role level, modified at the team level, and refined at the record and field level.
Single sign-on is available on the Scale tier. SAML 2.0 and OIDC are both supported. Domain verification locks the directory to a verified email domain. Just-in-time provisioning creates users on first sign-in. Deprovisioning on removal from the identity provider is synchronous, so a user offboarded in Okta loses access on their next request.
Multi-factor authentication is available on every tier and required for owner roles. TOTP and text-based verification are both supported. IP allowlisting is available on the Scale tier and can be scoped per role, so a sales team is reachable from anywhere while finance is scoped to the corporate network. Session policies cover idle timeout, absolute timeout, and concurrent session limits.
SAML and OIDC on Scale.
Enterprise identity providers connect through SAML 2.0 or OIDC. Domain verification locks the directory. Just-in-time provisioning creates users on first sign-in.
Available on every tier.
Multi-factor authentication is available for every user and required for owner roles. TOTP and text-based verification supported.
Scoped per role on Scale.
IP allowlisting locks access to approved network ranges. Scoped per role so sales reaches you from anywhere while finance stays on the corporate network.
Synchronous with the IdP.
A user offboarded in Okta or Entra loses access on their next request to Strkr. No stale session windows. No cron-job delay.
A plan written for the breach that has not happened yet.
Strkr maintains a documented incident response plan. The plan defines severity levels, the on-call rotation, the communication channels during an active incident, and the obligations to customers and regulators after one. The document exists, has been exercised, and is the input to the postmortems that follow every production incident.
Breach notification follows GDPR Article 33. In the event of a personal data breach, Strkr will notify affected customers without undue delay and within seventy-two hours of becoming aware of the breach, through the primary contact on the workspace account and through a secondary channel if the primary contact is the account that was affected. Customers in jurisdictions with stricter requirements receive notification on the earliest applicable schedule.
Postmortems are written for every production incident that crosses a severity threshold. The postmortem covers the root cause, the detection timeline, the user impact, and the follow-up work. For incidents that affected customer data, the postmortem is shared with the affected customers directly. The team's goal is to make incidents rare, and to make the ones that happen a learning event rather than a recurrence.
Data retention, backups, and the recovery window.
Audit logs are retained for twelve months on the Team tier and twenty-four months on the Scale tier. Workspaces that need longer retention can export the audit log to a workspace-owned destination (an S3 bucket, a SIEM, or a syslog receiver) through a scheduled export job that ships every entry to the destination within an hour of its creation.
Database backups run on a seven-day point-in-time recovery window with continuous write-ahead log shipping. Any committed transaction in the window is recoverable to any second. Backups are encrypted with AWS KMS and stored in a separate AWS account from the production database, which contains the blast radius of a credentials compromise.
Customer data is retained for the duration of the subscription plus thirty days after cancellation, to accommodate accidental cancellations and reactivations. At the thirty-day mark, the workspace is scheduled for deletion. Deletion propagates across the database, the object storage, the search index, and the backup store on the next backup cycle. Workspaces that want immediate deletion on cancellation can request it, and the request is honored within forty-eight hours.
12 months on Team, 24 on Scale.
Audit entries are retained inside Strkr for the window above. Scheduled export jobs ship entries to a workspace-owned destination for longer retention.
7-day point-in-time recovery.
Continuous WAL shipping. Any committed transaction is recoverable to any second in the window. Encrypted with KMS. Stored in a separate AWS account from the production database.
30-day grace, then gone.
Default retention is subscription + 30 days to catch accidental cancellations. Immediate deletion on request is honored within 48 hours. Deletion propagates to backups on the next cycle.
The paperwork, pre-filled.
Enterprise security questionnaires (SIG, CAIQ, VSA) are a solved problem on Strkr. Pre-filled responses to the standard frameworks are available to prospects under NDA, which cuts the typical two-week turnaround to a one-day review by your security team. The responses are maintained by the people who built the controls, not by a marketing team that paraphrases the engineering documentation.
Custom questionnaires are answered inside two business days for workspaces on the Scale tier. The responses are signed by a named engineer who can be looped into a follow-up call if your security team wants to validate anything. The point is to get out of your procurement team's way, not to pad the timeline with a vendor-review cycle.
For procurement teams that prefer a vendor-trust portal, Strkr maintains a shared folder of the current attestations, policies, and architecture documentation, access-granted on request. The folder is updated when the documents are updated, not on a quarterly cadence that ships stale evidence.
Try it free. Bring your team next week.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.