Security, uptime, residency, and backup posture decide whether a CRM clears procurement. This page covers how Strkr hosts customer data, the SLA commitments, the backup cadence, data residency options, and the compliance scope that comes with each.
CRM procurement blocks on five hosting questions almost every time: where does the data physically live, what happens if the primary region goes down, how often is it backed up and how fast can it be restored, which auditors have signed off on the environment, and how do we get our data out when we leave. Vague answers kill deals. Specific answers close them. Here are the concerns.
Prospects in regulated European industries need written confirmation that customer records, backups, and derivative processing stay in a specified region. A vendor that cannot answer the residency question with a region name on a page like this one gets filtered at procurement intake, not at the demo.
A 99.9 percent uptime commitment allows 43 minutes of downtime per month. A 99.5 percent commitment allows 3.6 hours. Procurement teams need the number in writing with the measurement window and the credit mechanism, not a marketing claim of high availability. Vague SLA language is a procurement blocker in regulated industries.
Daily backup is table stakes. Point-in-time recovery to the minute inside the last seven days is the real question. Retention of 30, 90, or 365 days differs by workload. Restore cadence to a staging environment measured in minutes versus hours differs by platform. Vendors who cannot answer these numbers lose procurement review.
Multi-tenant SaaS is the common model, and the question is not whether tenancy is shared but how isolation is enforced. Row-level security, encryption key separation, logical database isolation, and the control that prevents a bug from exposing tenant A data to tenant B. Procurement review wants evidence, not marketing copy.
SOC 2 Type II, HIPAA, GDPR, ISO 27001 compliance commitments need backing evidence: audit reports (NDA-gated), penetration test summaries, DPA templates ready to sign, and sub-processor lists ready to review. Vendors who stop at marketing claims lose the deal to vendors who publish the artifacts.
A procurement team evaluating a CRM factors in the exit cost from day one. If the data cannot be exported in a documented, machine-readable format with the full schema, the lock-in risk shows up as a line item in the risk register. CRMs that make exit a first-class feature win procurement. CRMs that bury the export feature lose.
Strkr runs on AWS across multiple Availability Zones in each supported region. The architecture is multi-tenant SaaS with logical isolation enforced at the row and tenant level, backed by encryption-key separation and strict permission scoping. Below are the pieces procurement reviewers tend to ask about.
The production environment runs across three Availability Zones in each region. Compute, database, cache, and object storage all span the three zones. A single-AZ failure (power, network, data center) does not take the service down. The failover is automatic and does not require manual intervention from a human operator.
Data at rest encrypts with AES-256 against AWS KMS-managed keys. Data in transit encrypts with TLS 1.2 or 1.3 across every public and inter-service connection. Customer-managed keys (CMK) are available for enterprise tiers that require them for regulatory reasons.
Multi-tenant isolation enforces at three layers: application-layer permission scoping on every API call, row-level security in the primary database, and per-tenant encryption context for sensitive derivative artifacts (file uploads, exports, backups). A single-layer bug does not expose cross-tenant data.
The database tier sits in private subnets with no public IP addresses. API traffic enters through managed load balancers at the edge. Inter-service traffic stays on VPC endpoints. Egress is restricted to defined destinations. The attack surface is the public API, not the datastore.
AWS Shield Standard covers volumetric DDoS at the edge. A managed WAF ruleset blocks the common injection patterns, geo-anomaly, and rate-based attacks. Shield Advanced is available for enterprise tiers that need the extra DDoS response coverage and the attack response credits.
Request tracing covers every API call, every background job, every email send, every webhook. Logs are scrubbed for customer PII at the edge; sensitive fields never land in observability pipelines. The engineering team can diagnose production without touching customer records.
Service-to-service credentials are short-lived and rotated automatically. Long-lived AWS keys do not exist in application code. Customer-provided API keys (for inbound webhooks or integrations) encrypt at rest with per-tenant encryption context and are never logged in plaintext.
Deployments run through staged rollouts: canary cohorts receive the new build first, metrics are compared against baseline, and the rollout either continues or auto-rolls back. Customers rarely see a deploy; the service does not drop traffic for a release.
Every production change (code, infrastructure, configuration) is version-controlled, peer-reviewed, and tagged with the change ticket. Change-management artifacts are retrievable for audit. The posture meets SOC 2 and HIPAA change-management controls out of the box.
Procurement needs specific numbers. The SLA tier, the measurement methodology, the exclusion windows, and the credit mechanism all live in the Master Service Agreement and the published Service Level Agreement. Here are the specifics.
Standard customers receive a 99.9 percent monthly uptime commitment, measured as successful API responses against total requests across a rolling monthly window. The 99.9 commitment allows roughly 43 minutes of downtime per month. Enterprise tier upgrades the SLA to 99.95 percent with the exact terms in the executed agreement.
Breach of the SLA threshold in a given month results in service credits applied to the next invoice. The credit tier scales with the duration of the breach. The credit application is automatic on paid annual contracts; no customer-side claim form is required. The credit percentages live in the SLA document.
The public status page shows real-time uptime for the API, the application, the integrations layer, the background job tier, Strkr Messaging, and the authentication service. Incidents are posted within minutes with impact descriptions and ETA. Post-incident reports publish within five business days of resolution.
Scheduled maintenance windows are posted at least 72 hours in advance on the status page and emailed to the primary technical contact. Zero-downtime deploys are the norm; windows requiring downtime are rare and limited to major infrastructure migrations with explicit customer notice.
On-call engineering covers production around the clock with escalation paths through engineering management and executive leadership. Severity 1 incidents trigger inside five minutes of detection. The response-time commitments live in the SLA document and apply across every region.
The trailing 12-month uptime record publishes quarterly on the trust center page. Prospects evaluating procurement see the actual historical attainment, not just the SLA threshold. The transparency pre-empts the question that procurement teams always ask.
Backup posture decides what happens on the worst day. Point-in-time recovery, retention windows, restore cadence, and the durability guarantee all factor in. Here are the specifics.
The primary database supports point-in-time recovery to the minute inside a rolling seven-day window. A tenant-level restore request runs through the customer success team with a target completion inside four hours for Standard and inside two hours for Enterprise. The restore is to a sandbox for review before replacing production.
Daily snapshots retain for 30 days on Standard tier and up to 365 days on Enterprise. Snapshots are stored in a separate AWS account under a different KMS context to protect against ransomware or compromise of the primary environment. The snapshot cadence is non-negotiable.
Primary database snapshots replicate asynchronously to a secondary region. Recovery Time Objective (RTO) sits at 4 hours; Recovery Point Objective (RPO) sits at 15 minutes. The disaster recovery runbook is available under NDA for enterprise prospects reviewing procurement risk.
File attachments, document uploads, and export archives sit on S3 with 11-nines durability and multi-AZ redundancy by default. Enterprise tiers can elect cross-region replication for the object tier with the attendant transfer and storage cost adjustment.
The admin export surface produces a full-tenant archive in a documented, machine-readable format with the complete schema. Exports run on demand or on a scheduled cadence (weekly or monthly). The export is a first-class feature, not a courtesy, and procurement reviewers see it as the exit assurance it is meant to be.
The engineering team runs quarterly restore drills from backup to a parallel environment. The drill validates that backups are usable, that the restore runbook works, and that the RTO and RPO numbers hold. Drill summaries are available in the trust center for prospects who want evidence of operational discipline.
Data residency is a procurement-blocking question for regulated industries, European prospects, and public-sector adjacent buyers. The policy is explicit and the regions are specific.
Standard tenants land in us-east-2 by default. Customer records, backups, derivative processing, and object storage all stay in the region. The region selection is visible to tenant admins and documented in the DPA for European or regulated prospects.
European tenants provision into eu-west-1 at tenant creation. Data never leaves the region for routine processing. Sub-processors and third-party integrations that touch customer data (email delivery, Strkr Messaging) are selected for EU-region support. The DPA documents each sub-processor in the compliance scope.
Operational tooling (observability, exception reporting) runs with PII-scrubbed telemetry so engineering can diagnose issues without data crossing regional boundaries. Any support request requiring access to customer records occurs through a documented access-request workflow with customer admin visibility.
The current sub-processor list is published on the trust center with the sub-processor name, service purpose, and data residency. Changes to the sub-processor list are notified in advance to tenants on the enterprise tier so compliance teams can review before go-live.
The Data Processing Agreement including Standard Contractual Clauses is available for execution with any customer that requires it. The DPA covers GDPR obligations, cross-border transfer mechanisms, and sub-processor flow-down obligations. Enterprise tenants receive a dedicated privacy point of contact.
For public sector adjacent prospects or regulated industries requiring FedRAMP-equivalent controls, the engineering team maintains a controls mapping. A FedRAMP-authorized environment is on the roadmap and specific procurement conversations should route through the enterprise team for current status.
Prospects sometimes ask whether Strkr can be self-hosted on their infrastructure. The current answer is no, and the trade-off is specific. Below is the direct comparison between the hosted-SaaS model and a self-hosted alternative, so procurement reviewers can decide with full information.
Self-hosted CRM typically consumes 1 to 3 full-time engineers on infrastructure, upgrades, security patching, backup management, and incident response. Hosted SaaS consumes zero. For most organizations, the labor cost of self-hosting exceeds the hosted license cost by a factor of 5 to 10.
The Strkr platform ships multiple times per week to all hosted customers. Self-hosted customers inevitably lag behind, miss security patches, miss feature releases, and build up upgrade debt. The gap is 6 to 18 months within two years. Hosted customers do not accumulate the debt.
HIPAA (with BAA), GDPR, CCPA, and SOC 2 Type II (in progress through 2026-Q4) scopes apply to the hosted environment and the controls that Strkr operates. A self-hosted model would require the customer to maintain the equivalent control set on their own infrastructure. For most teams, the scope is prohibitive.
For enterprise tenants with specific isolation requirements, a single-tenant deployment inside the Strkr-managed cloud is available on request. The database, cache, and background job tiers run on dedicated infrastructure for the tenant. The customer still does not operate it, Strkr does, with the dedicated-infrastructure premium.
Fully air-gapped on-premises deployments are not supported. The product depends on continuously improving background services (Strkr AI, Strkr Messaging, scheduled scans) that assume connectivity to Strkr infrastructure. Procurement reviewers evaluating against air-gap requirements should route through the enterprise team.
The REST API, webhooks, event stream, and full-tenant export give customers complete access to their data at any time. The data lock-in risk that procurement teams flag with hosted SaaS is addressable through the export posture and the open API, both of which are first-class features, not afterthoughts.
The posture differences between Strkr hosting and the SMB-market CRM hosting that typically shows up next in procurement review.
| Feature | Strkr | Typical SMB CRM hosting |
|---|---|---|
| Primary infrastructure | AWS multi-AZ across three zones per region | Shared cloud infrastructure, often single-AZ |
| Monthly uptime SLA | 99.9 percent Standard, 99.95 percent Enterprise | Often 99.5 percent or marketing claim without contract |
| Point-in-time recovery | To the minute inside 7 days | Daily snapshots at best, often opaque |
| Snapshot retention | 30 days Standard, up to 365 Enterprise | Usually 7 to 30 days with no premium option |
| Cross-region DR | Async replication, 4-hour RTO, 15-min RPO | Not standard; often requires paid add-on |
| Data residency | US (us-east-2) and EU (eu-west-1) regions | Often US-only; EU as a premium add-on |
| DPA with SCCs | Ready to execute at any tier | Enterprise-only or legal review on request |
| Sub-processor transparency | Published, versioned, change-notified | Often on request only |
| Full-tenant export | First-class admin feature, machine-readable schema | Hidden in support channel, CSV-only |
| Compliance posture | HIPAA with BAA, GDPR, CCPA, SOC 2 Type II in progress | Varies; often HIPAA not supported |
| Historical uptime | Trailing 12-month record published quarterly | Not published or hard to find |
| Private tenant option | Single-tenant deployment available Enterprise | Often not available |
Four patterns from recent procurement reviews that cleared the hosting posture. Each shows the concern, the artifact that satisfied it, and the outcome.
A 40-user fintech based in Dublin needed written confirmation that customer data stayed in Ireland and a DPA with SCCs ready to execute. The sales team sent the DPA, the sub-processor list, and the residency statement on day one. Procurement signed off in two business days. The alternative CRM in the running stalled for three weeks on the DPA request.
A healthcare SaaS with HIPAA scope needed a signed BAA plus audited evidence of SOC 2 Type II readiness. Strkr provided the BAA, the SOC 2 Type II readiness status (in progress through 2026-Q4), and the current control mapping. The risk register accepted the posture with a review in Q1 2027 at Type II issuance.
A 180-user manufacturing enterprise required dedicated database and cache tiers for their deployment. Strkr enterprise team scoped the single-tenant deployment inside the Strkr-managed cloud. The customer accepted the dedicated-infrastructure premium in exchange for isolation certainty. Go-live inside 10 weeks.
A European multinational had a hard requirement that every sub-processor touching customer data be reviewable before go-live, with change notifications before new sub-processors were engaged. Strkr sub-processor list and change-notification policy met the requirement. Procurement signed. The alternative vendor could not produce a list.
A 25-user growth-stage SaaS skipped a formal procurement review because the 14-day trial ran on the same production infrastructure as paid customers with the same compliance posture. The security review happened in parallel with the pilot. The team cleared security and expanded to 48 seats inside two months with no renegotiation.
The DPA, sub-processor list, SLA document, SOC 2 Type II progress status, and HIPAA BAA are all available on request through the trust center or the sales team. Procurement reviewers get the artifacts they need to clear the risk register. Start a 14-day trial on production infrastructure or route an enterprise conversation through the sales team.
Standard tenants host in AWS us-east-2 (Ohio) across three Availability Zones. European tenants provision into AWS eu-west-1 (Ireland) with full regional isolation. The region selection is explicit in the tenant admin surface and documented in the DPA. Cross-region data flow is restricted and audited; routine processing does not cross regional boundaries.
Standard tier commits to 99.9 percent monthly uptime, which allows roughly 43 minutes of downtime per month. Enterprise tier upgrades to 99.95 percent. The SLA is measured against the public status page uptime record and credits apply automatically on breach for paid annual contracts. The trailing 12-month attainment record publishes quarterly on the trust center.
The primary database supports point-in-time recovery to the minute inside a rolling seven-day window. Daily snapshots retain for 30 days on Standard tier and up to 365 days on Enterprise. Snapshots are stored in a separate AWS account with a different KMS context, protecting against ransomware or compromise of the primary environment. A tenant-level restore request runs through customer success with a 4-hour target on Standard and 2-hour target on Enterprise.
Strkr is HIPAA compliant with a BAA available on request, GDPR and CCPA compliant, and SOC 2 Type II is in progress through the fourth quarter of 2026. The compliance scope is maintained by Strkr for all hosted customers; a single audit cadence covers the full platform. Audited artifacts (SOC 2 reports, penetration test summaries) are available under NDA through the trust center.
No. Fully self-hosted or on-premises deployments are not supported. The product depends on continuously improving background services (Strkr AI, Strkr Messaging, scheduled scans) that assume connectivity to Strkr infrastructure. Enterprise prospects with specific isolation requirements can provision a dedicated single-tenant deployment inside the Strkr-managed cloud, where the customer still does not operate it but gains infrastructure isolation.
The admin surface produces a full-tenant export in a documented, machine-readable format covering the complete schema (records, relationships, custom fields, file attachments, audit history). Exports run on demand or on a scheduled cadence (weekly or monthly). The export is a first-class feature and the schema is published, so a receiving system can map against a known specification rather than guess.
Primary database snapshots replicate asynchronously to a secondary region. Recovery Time Objective sits at 4 hours and Recovery Point Objective sits at 15 minutes. A region-wide outage triggers the documented disaster recovery runbook, with executive escalation and customer communication through the status page. Full region-wide outages are rare in modern AWS infrastructure, and the posture is designed to handle them within the published RTO and RPO.
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.
