Building in the Open: Our Security Posture While SOC 2 and GDPR Certification Is Underway 🔒
Why We're Talking About Security Before the Badges Arrive
Most companies wait until the certificate is framed on the wall before publishing a single word about security. We think that's backward.
KredSLA handles sensitive data — cloud credentials, billing metrics, support case histories — on behalf of organizations that trust us to recover SLA credits across AWS, Azure, GCP, and OCI. That trust begins before a formal audit opinion is issued.
We are actively pursuing SOC 2 Type I and GDPR compliance. Rather than treat it as a checkbox exercise, we've used the process to systematically harden every layer of the platform. This post details where we stand today, what controls are already in production, and what remains.
What SOC 2 and GDPR Actually Mean for a SaaS Platform
SOC 2 evaluates whether an organization has designed and implemented controls across five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. A Type I report assesses control design at a point in time; Type II proves those controls operate effectively over a sustained period.
GDPR governs how personal data of EU residents is collected, processed, stored, and deleted. For a B2B SaaS platform, this means implementing robust data minimization, transparent processing, and enforceable data subject rights.
Both frameworks share a core requirement: demonstrable, auditable security — not just policy documents.
Authentication and Access Control
Security starts at the front door. KredSLA supports multiple authentication methods, all enforced in production today:
- Enterprise SSO via Google Workspace, Microsoft Entra ID (Azure AD), Okta, and JumpCloud — supporting both OIDC and SAML flows
- Email + password authentication with enforced complexity requirements (minimum 12 characters, mixed case, numbers, and special characters) and passwords hashed using bcrypt
- Two-factor authentication (2FA) via email-delivered one-time codes, backed by Redis with strict TTLs
- Short-lived JWT tokens with org-scoped claims — tokens expire quickly and are bound to a single organization
- Rate limiting on all authentication endpoints to prevent credential-stuffing attacks
- Secure, HttpOnly session cookies with CSRF protection — secure transport enforced outside of local development
- Production secret key guard — the API refuses to start if a default or weak signing key is detected in a production environment
Every API request is scoped to the caller's organization. There is no cross-tenant data access.
Credential Storage: Zero Trust by Design
KredSLA requires cloud provider credentials to perform discovery scans and file SLA claims. These credentials — IAM role ARNs, service principal keys, OCI API keys — are never stored in the application database.
Instead, all credentials are written to OpenBao (an open-source fork of HashiCorp Vault) using the KV v2 secrets engine. The database stores only an opaque reference identifier — never the credential material itself.
Credentials are fetched at task execution time by background workers, used, and never cached. A database constraint enforces that vault references conform to a validated format — preventing path traversal or injection at the data layer.
When an organization is deleted, credentials are immediately purged from both the database and the secrets store.
Data Retention and the Right to Erasure
We maintain a formal data retention policy aligned with both GDPR Article 5(1)(e) and SOC 2 CC6 requirements:
| Data Category | Retention | Rationale |
|---|---|---|
| Active user accounts | While account is active | Contract performance |
| Cloud credentials (Vault) | While account is active | Purged on deletion |
| SLA claim records | 7 years post-resolution | Financial/tax compliance |
| Claim audit logs | 7 years | SOC 2 CC7 |
| Auth event logs | 1 year | Security monitoring |
| Redis session/cache data | 15 min – 1 hour (TTL) | Ephemeral by design |
| Deleted organization data | Immediate (DB) / 30 days (backups) | GDPR Article 17 |
When a data subject exercises their right to erasure (GDPR Article 17), the following cascade executes:
- The organization and all child records are deleted immediately from PostgreSQL
- Cloud credentials are purged from OpenBao
- Redis cache entries are cleared
- An
ACCOUNT_DELETEDevent is written to the auth audit log - Backup data is purged within 30 days via automated snapshot rotation
This is not a manual process — it is a tested, automated deletion endpoint (DELETE /api/v1/privacy/account) with full cascading semantics.
Backup and Disaster Recovery
Data durability is a SOC 2 availability requirement (CC7) and a practical necessity. Our backup strategy covers all persistent stores:
PostgreSQL (AWS RDS):
- Daily automated snapshots with 30-day retention
- Point-in-time recovery enabled with ≤ 5-minute RPO
- AES-256 encryption at rest via AWS KMS
- Multi-AZ deployment with synchronous standby
- Cross-region read replica in a secondary AWS region for disaster recovery
- Weekly SQL exports to S3 with lifecycle policies (Glacier after 30 days, purged after 1 year)
OpenBao (Vault):
- Daily Raft snapshots stored in encrypted S3
- Auto-unseal with AWS KMS
Redis:
- Not backed up by design — all Redis data is ephemeral (TTL ≤ 1 hour) and fully reconstructible from the database
Recovery targets: RPO ≤ 5 minutes, RTO ≤ 1 hour. Snapshot restores are tested monthly, PITR restores quarterly, and full disaster recovery exercises are conducted annually.
Audit Logging and Monitoring
Every security-relevant action is logged with structured context:
- Authentication events — login attempts, SSO flows, 2FA verifications, failed logins — are recorded in a dedicated auth audit log
- Claim lifecycle events — detection, evidence bundling, filing, approval, rejection — are tracked in an immutable claim audit log
- Structured JSON logging is enabled across the API, ready for ingestion by CloudWatch, Azure Monitor, or any log aggregation platform
- Health checks verify database and Redis connectivity in real time — the
/healthendpoint returns HTTP 503 on failure, enabling automated alerting
CI/CD Security Pipeline
Code changes go through an automated security gauntlet before reaching production:
- Static analysis (SAST) on all Python and TypeScript code
- Dependency auditing for both backend and frontend package ecosystems
- Container scanning for known CVEs in all Docker images
- Automated compliance tests validating authentication flows, access controls, and data handling behaviors
- Strict lint and test gates — pull requests cannot merge without passing the full CI pipeline
Incident Response
We maintain a documented incident response plan with defined severity levels, response SLAs, and escalation procedures:
| Severity | Example | Response SLA |
|---|---|---|
| P1 — Critical | Active data breach, production down | Within 15 minutes |
| P2 — High | Suspicious auth spikes, vault access failures | Within 1 hour |
| P3 — Medium | Dependency CVE, misconfiguration | Within 24 hours |
| P4 — Low | Hardening opportunity, documentation gap | Next sprint |
The plan includes containment checklists, forensic evidence preservation procedures, and GDPR-compliant breach notification — supervisory authority notification within 72 hours per Article 33, with a pre-drafted notification template.
Vulnerability Disclosure
We operate a public vulnerability disclosure policy. Security researchers can report findings to security@kredsla.com with a commitment to:
- Acknowledgment within 2 business days
- Assessment within 5 business days
- Critical vulnerability resolution within 30 days
- Safe harbor for good-faith research conducted within policy scope
Legal and Privacy Framework
All legal documents are published and accessible within the application:
- Privacy Policy — defines lawful basis for processing, data minimization practices, subprocessor list, international transfer safeguards (Standard Contractual Clauses), and data subject rights
- Terms of Service — contractual framework for platform use
- Data Processing Agreement (DPA) — processor obligations, audit rights, subprocessor controls per GDPR Article 28
- Cookie consent banner — active in the frontend with consent tracking
What's Left: The Organizational Layer
All code-level, operational, and frontend compliance controls are implemented and tested. The remaining items before formal certification are organizational, not technical:
- Legal counsel review of template documents (Privacy Policy, DPA, Terms)
- Annual penetration testing — scheduling with a third-party vendor
- Tabletop incident response exercise — simulating a P1 scenario
- MDM and HR on/offboarding — formal employee device management and access lifecycle processes
- GitHub branch protection rules — repository-level enforcement settings
- Log shipping configuration — connecting structured JSON logs to a centralized monitoring destination
These are process and vendor items — the engineering and application security work is done.
Why This Matters for Our Customers
If you're evaluating KredSLA, you're trusting us with access to your cloud environment. That decision should be informed by specifics, not marketing language.
Here's what's true today:
- Your credentials never touch our database
- Your data is encrypted at rest and in transit
- Deletion requests cascade immediately across all data stores
- Every authentication and claim event is audit-logged
- Our CI/CD pipeline enforces security scanning on every commit
- We have defined, tested incident response procedures
- We are actively pursuing formal SOC 2 Type I and GDPR certification
We'll publish updates as we progress through the audit process. In the meantime, the controls described above are live — not planned — and reflect how we operate every day.
Conclusion
Compliance certifications validate what should already be true about how you build and operate software. By the time the SOC 2 Type I report and GDPR assessment are finalized, they will confirm controls that have been running in production for months.
Security is not a milestone — it's architecture.
We believe customers deserve transparency about where that architecture stands, especially during the period when formal validation is in progress. This post is our commitment to that transparency.
Questions about our security practices? Reach out at security@kredsla.com.