Security is the product — and how we run the company.
RedStrike simulates real attacks against your systems, so we hold our own platform to the standard we ask of yours: encryption everywhere, hard tenant boundaries, least-privilege access, and testing that is always scoped and authorized.
Data handling
What data do we collect, and how little can we keep?
We practice data minimization: RedStrike stores what is required to find, verify, and prioritize vulnerabilities — and nothing more.
Data minimization
We collect scan targets, discovered assets, and finding evidence. We do not need production data dumps, customer PII, or standing access to your applications to operate.
Purpose limitation
Data is used only to run scans, verify exploits, generate reports, and improve your security posture — never sold, and never used to train third-party models.
Retention & deletion
Findings and reports follow configurable retention windows. On request or contract termination, we delete customer data and confirm removal from backups on a defined schedule.
Encryption
How is data protected in transit and at rest?
Strong, modern cryptography is applied by default across the platform — there is no unencrypted path for customer data.
In transit: TLS 1.2+
All connections to RedStrike — UI, API, and live scan streams — are encrypted with TLS 1.2 or higher, with modern cipher suites and HSTS enforced at the edge.
At rest: AES-256
Databases, object storage, backups, and generated HTML/PDF reports are encrypted at rest with AES-256. Encryption keys are managed through a dedicated KMS with rotation.
Tenant isolation
How do you keep one customer's data from another's?
RedStrike is multi-tenant by design, with a tenant identifier enforced on every request, query, and background job.
- Every record — scans, assets, findings, reports — is scoped to a tenant ID that is checked on read and write.
- Scan workers run jobs bound to a single tenant context; results never cross tenant boundaries.
- API authorization is evaluated per tenant and per role before any data is returned.
- Object storage paths and report artifacts are namespaced and access-controlled per tenant.
Defense in depth
Isolation is enforced at the application, query, and infrastructure layers rather than trusting a single control. Our own continuous testing includes checks for cross-tenant access, IDOR, and broken object-level authorization on the platform itself.
Authentication & access
Who can get in, and how is access controlled?
Access is authenticated, role-scoped, and least-privilege — for your team and for ours.
SSO: SAML & OIDC
Bring your identity provider. RedStrike supports SSO via SAML 2.0 and OIDC so access follows your central provisioning and de-provisioning.
RBAC
Role-based access control governs who can launch scans, view findings, export reports, and manage billing — scoped to each workspace.
MFA
Multi-factor authentication is supported for all accounts and can be enforced org-wide, including for administrative actions.
Least privilege
Internal access to production is limited, logged, and granted just-in-time. Engineers receive only the access a task requires, and access is reviewed regularly.
Authorized testing
How do you make sure testing is safe and in-scope?
RedStrike only tests systems you own or are authorized to test, within agreed rules of engagement.
Rules of engagement
Before testing begins, scope, targets, allowed windows, and exclusions are agreed in writing. Ownership of in-scope assets is verified so scans never reach systems you have not authorized.
Non-destructive verification
Exploit verification is designed to confirm a vulnerability is real without causing damage or exfiltrating data — the safe path to eliminating false positives and producing verified findings.
Tight scoping & audit trail
Rate limits, allow-lists, and per-tenant scoping keep tests contained, and every scan is logged with who initiated it, against what, and when.
Subprocessors
Which subprocessors help run RedStrike?
We use a small, vetted set of subprocessors, each bound by data-protection terms. Current subprocessors are listed below.
| Subprocessor | Purpose | Region |
|---|---|---|
| Amazon Web Services (AWS) | Primary cloud hosting, compute, and encrypted storage | US / EU (customer-selectable) |
| Postmark | Transactional email (verification, alerts, reports) | United States |
| Sentry | Application error monitoring and performance tracing | United States / EU |
| Cloudflare | DNS, WAF, TLS termination, and DDoS protection | Global edge network |
Data-processing terms are covered by our Data Processing Agreement. Customers can subscribe to advance notice of material subprocessor changes.
Compliance posture
Where are you on compliance and certifications?
We build to recognized frameworks and are transparent about what is in place today versus in progress.
SOC 2 Type II — in progress
We are undergoing a SOC 2 Type II examination covering security, availability, and confidentiality. The report will be available to customers and prospects under NDA.
ISO 27001 — aligned
Our information security management program is aligned to ISO 27001 controls, with formal certification on our roadmap.
Helps you comply
RedStrike testing and reporting map to SOC 2, ISO 27001, and PCI DSS evidence needs — see compliance solutions.
Responsible disclosure
Found an issue in RedStrike? Read our policy and report it safely.
Data Processing Agreement
Review how we process customer data as your processor.
Security questions or a questionnaire to complete? Email security@encyfr.ai.
FAQ
Frequently asked questions
Common questions from security and procurement teams.
How does RedStrike keep multi-tenant data isolated?
Every scan, asset, finding, and report is scoped to a tenant identifier that is enforced on every API request, database query, and background scan job. Authorization is evaluated per tenant and per role before any data is returned, and object storage is namespaced per tenant. We also run our own continuous tests for cross-tenant access and broken object-level authorization.
What encryption does RedStrike use?
All data in transit is encrypted with TLS 1.2 or higher using modern cipher suites, with HSTS enforced. Data at rest — databases, object storage, backups, and generated reports — is encrypted with AES-256, and keys are managed in a dedicated KMS with rotation.
Does RedStrike need standing access to our production systems?
No. RedStrike operates on the scan targets and scope you authorize and does not require production data dumps or persistent credentials into your applications. Cloud posture (CSPM) scanning uses least-privilege, read-only roles you control and can revoke at any time.
How do you make sure testing stays authorized and non-destructive?
Testing only runs against systems you own or are authorized to test, within written rules of engagement that define scope, targets, windows, and exclusions. Exploit verification confirms a vulnerability is real without causing damage or exfiltrating data, and rate limits, allow-lists, and per-tenant scoping keep every scan contained and logged.
Is RedStrike SOC 2 or ISO 27001 certified?
RedStrike is undergoing a SOC 2 Type II examination covering security, availability, and confidentiality; the report will be shared with customers and prospects under NDA. Our security program is aligned to ISO 27001 controls, with formal certification on our roadmap.
How can I report a vulnerability in RedStrike itself?
We welcome reports from security researchers. Review our responsible-disclosure policy at /legal/responsible-disclosure for scope and safe-harbor guidance, or email our security team at security@encyfr.ai directly.
Run security reviews with a vendor that lives it
See how RedStrike verifies real vulnerabilities safely — with encryption, tenant isolation, and authorized testing built in.