The security posture is built on standard AWS services rather than custom encryption schemes. The pattern is deliberately boring because boring survives procurement review and audit scrutiny.
Strkr uses AWS KMS to encrypt integration tokens (Shopify, Meta CAPI, Resend, webhook signing secrets), AWS Secrets Manager for platform credentials, TLS 1.2 or newer for all data in transit, and AWS-managed encryption at rest on RDS for the primary database. The combination is a standard AWS-native security posture that satisfies HIPAA, GDPR, CCPA, and the SOC 2 Type II audit currently in progress with target delivery in 2026-Q4.
The four encryption layers in the Strkr security posture, each with a specific scope and purpose.
Integration credentials (Shopify API tokens, Meta Conversions API tokens, Resend keys, webhook signing secrets) are encrypted with AWS KMS. Each tenant's integration tokens are isolated. KMS handles key rotation and access control. The pattern is standard AWS-native encryption for sensitive data at the application layer.
Platform credentials (database passwords, service-to-service tokens, admin API keys) live in AWS Secrets Manager. Secrets Manager handles rotation on scheduled intervals and provides audit logs of every access. Platform credentials are never in source code, environment files, or build artifacts.
All data in transit between clients and the Strkr API is encrypted with TLS 1.2 or newer. Internal service-to-service traffic within AWS also runs over TLS. There is no unencrypted path for customer data. The TLS posture is enforced at the load balancer and the application layer.
The primary database (PostgreSQL on RDS) uses AWS-managed encryption at rest. Database files, backups, and snapshots are encrypted. The pattern is AWS-native and transparent to the application layer. Encryption keys are managed by AWS KMS, following the same pattern as integration-token encryption.
The combined encryption posture supports HIPAA compliance (BAA available), GDPR and CCPA compliance, and the SOC 2 Type II audit currently in progress with target delivery in 2026-Q4. The posture is documented in the trust center and reviewed with every enterprise procurement process.
The four layers each solve a specific security problem. The details below are what a security review usually asks for during enterprise procurement.
When a tenant connects Shopify, Meta CAPI, Resend, or configures webhook signing, the credentials get stored encrypted with AWS KMS. Each tenant's integration tokens are isolated so no cross-tenant exposure is possible. The encryption key management uses AWS-native KMS features including rotation.
Database passwords, service-to-service authentication tokens, and administrative API keys live in AWS Secrets Manager. Secrets rotate on scheduled intervals. Every access is logged and auditable. No credential appears in source code, environment files, container images, or build artifacts.
TLS 1.2 or newer is enforced at the load balancer. Weak cipher suites are disabled. Certificate renewal is automated through AWS Certificate Manager. Internal service traffic is also TLS-encrypted. The posture leaves no unencrypted path for customer data between the client and the database.
The primary PostgreSQL database runs on AWS RDS with encryption at rest enabled. Database files on disk, automated backups, manual snapshots, and replica databases are all encrypted. Encryption keys are managed by AWS KMS, so the same key rotation discipline applies at the storage layer.
All encryption keys are managed by AWS KMS, which handles rotation, access control, and audit logging centrally. Strkr does not implement custom encryption schemes or roll its own cryptography. The pattern uses standard AWS services deliberately because standard patterns survive audit scrutiny.
Access to encrypted resources is logged through AWS CloudTrail and internal audit logs. Access logs are retained for the duration required by relevant compliance frameworks (SOC 2, HIPAA, GDPR). Logs are reviewed during periodic security assessments and are available for customer audit on request.
Security posture is never finished. The elements below are specific improvements under active work. The published trust center carries the current state.
The SOC 2 Type II audit is in progress with target delivery in Q4 of 2026. The audit covers the full security posture: encryption, access control, change management, incident response, and vendor management. The attestation report will be available on request after completion.
Customer-managed KMS keys (where enterprise customers bring their own AWS KMS key for data encryption) are on the roadmap. The feature serves enterprise customers with specific regulatory or policy requirements around key management. Target timing is coordinated with the SOC 2 Type II delivery.
Verified Domains for enterprise single-sign-on identity verification are planned under the auth roadmap. Combined with session policy, password policy, and IP allowlist (already live), the auth posture matches enterprise expectations when the feature ships.
Single sign-on and multi-factor authentication are planned features under the auth roadmap. Session policy, password policy, and IP allowlist are already live. The complete enterprise auth suite ships together in a planned release coordinated with the trust center update.
Field-level permissions (restricting access to specific record fields based on user role) are planned inside the broader Layouts work. The feature serves enterprise motions where certain fields contain sensitive data that only specific roles should see. Timing follows the Layouts release.
The security posture is reviewed continuously. Dependency updates follow a defined cadence. Infrastructure changes go through security review. Incident response processes are tested periodically. The practices are documented and audited as part of the SOC 2 Type II program.
Clear positioning on what is not used matters as much as what is used. The absence of custom cryptography is deliberate. The absence of some features is a roadmap statement.
Strkr does not implement custom encryption algorithms, home-rolled cryptography, or novel key management schemes. Every encryption primitive comes from AWS KMS, AWS Secrets Manager, or standard TLS. The pattern is deliberately conservative because audit review favors conservative patterns.
Strkr does not provide end-to-end encryption where the server cannot read customer data. CRM functionality requires server-side access to data for search, reporting, and automation. The posture is server-side encryption at rest and in transit, which is standard for operational CRM systems.
Customer-managed KMS keys (bring your own key) are not yet available. The feature is on the roadmap for enterprise customers with specific requirements. Current encryption uses AWS-managed keys, which satisfies the HIPAA, GDPR, and CCPA compliance scope.
Strkr runs in AWS. There is no on-premise or private-cloud deployment option. The security posture is designed around AWS-managed services. Teams with regulatory requirements that mandate on-premise deployment are not a Strkr fit today.
For teams enabling the Strkr AI module, calls to the underlying AI provider flow through Strkr's infrastructure. Customer AI provider keys are not supported. The buyer does not configure or manage AI model credentials. The pattern keeps the usage billing clean and the compliance surface auditable.
Integration tokens and tenant-specific credentials are isolated per tenant. There is no shared tenancy of secrets across customers. The isolation is enforced at the KMS key policy level and the application layer. Cross-tenant data exposure is not possible by design.
The published trust center carries the current encryption posture, compliance scope, incident response summary, and the SOC 2 Type II progress. BAAs and compliance documents are available on request through the Strkr team.
Yes. Strkr is HIPAA compliant with a Business Associate Agreement available on request. The combined encryption posture (AWS KMS for tokens, AWS Secrets Manager for platform credentials, TLS in transit, AWS-managed encryption at rest on RDS) supports the technical safeguards required by HIPAA.
SOC 2 Type II is in progress with target delivery in 2026-Q4. The audit covers the full security posture including encryption, access control, change management, and incident response. The attestation report will be available on request after completion.
Yes. The primary PostgreSQL database runs on AWS RDS with encryption at rest enabled. Database files, backups, and snapshots are encrypted using AWS KMS-managed keys. The posture is AWS-native and standard for SaaS applications handling customer data.
Integration tokens for Shopify, Meta Conversions API, Resend, and webhook signing secrets are encrypted with AWS KMS. Each tenant's integration tokens are isolated. The encryption applies at the application layer in addition to the AWS-managed encryption at the storage layer.
Not today. Customer-managed KMS keys are on the roadmap for enterprise customers with specific requirements. Current encryption uses AWS-managed keys, which satisfies HIPAA, GDPR, and CCPA compliance scopes. The feature targets delivery coordinated with SOC 2 Type II.
Primary data lives in AWS, in regions configured for the Strkr platform. The data center choice supports compliance requirements including HIPAA and GDPR. Enterprise customers with region-specific requirements should contact the Strkr team to confirm the current deployment region and roadmap.
AWS Secrets Manager rotates platform credentials on scheduled intervals. KMS keys rotate on AWS-managed schedules. Integration tokens issued by third parties follow the issuer's rotation policy. The combination gives a predictable key hygiene posture that aligns with SOC 2 Type II audit expectations.
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.
