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:

When a data subject exercises their right to erasure (GDPR Article 17), the following cascade executes:

1. The organization and all child records are deleted immediately from PostgreSQL
2. Cloud credentials are purged from OpenBao
3. Redis cache entries are cleared
4. An ACCOUNT_DELETED event is written to the auth audit log
5. 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 /health endpoint 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:

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.

FinOps has transformed how organizations manage cloud spending.
Teams now understand where money goes, how usage drives cost, and how to optimize consumption.

Yet one major category of financial loss remains largely invisible:

Paying full price when providers fail to deliver contracted reliability.​

Cloud vendors publish uptime guarantees. Contracts define compensation for service failures. But in practice, most organizations do not recover what they are owed.

The result is a silent but systemic form of overspend.

Visibility Is Not Control​

Modern FinOps tooling answers questions like:

• Which services drive our spend?
• Where can we right-size usage?
• Are we forecasting accurately?
• How do we allocate costs internally?

But when outages or degradations occur, billing does not automatically adjust.

Credits typically require customers to:

• Detect violations
• Gather evidence
• Interpret complex SLA formulas
• Submit claims within strict deadlines
• Track resolution across support channels

For organizations operating at cloud scale, this process is rarely sustainable.

The Economics of Unclaimed Entitlements​

Even mature teams often recover only a fraction of eligible compensation. Reasons include:

• Responsibility is unclear across teams
• Incidents affect multiple services simultaneously
• Partial degradations are difficult to quantify
• Claim windows are short
• Documentation requirements are strict
• Recovery effort may exceed perceived benefit

Over time, these missed opportunities accumulate into meaningful financial leakage.

Unlike traditional waste, this loss is not visible in cost dashboards — because it represents money that should have been returned but was never requested.

Why This Matters More Now​

Cloud Is No Longer Experimental​

Core business operations depend on third-party infrastructure. Downtime directly affects revenue, productivity, and customer trust.

When reliability becomes mission-critical, compensation mechanisms become financially relevant.

Architectures Are Increasingly Complex​

Multi-region, multi-service, and multi-cloud deployments create layered dependencies. Determining whether a contractual violation occurred requires correlating provider incidents with internal telemetry.

Manual analysis does not scale with this complexity.

Financial Discipline Has Tightened​

Organizations face sustained pressure to control operating expenses without slowing innovation.

Recovering value already contractually promised is one of the least disruptive ways to reduce effective spend.

No migrations. No redesigns. No usage reductions.

From Cost Optimization to Cost Assurance​

FinOps has traditionally focused on optimizing how resources are consumed.

SLA enforcement introduces a complementary concept:

Ensuring organizations pay only for delivered performance.​

This shifts the conversation from efficiency to entitlement.

It is not about using less cloud — it is about receiving what was promised for what you use.

The Operational Gap Between Finance and Engineering​

Reliability data lives with DevOps and SRE teams.
Financial accountability lives with FinOps and procurement.

Without automation, bridging these domains requires coordination across functions that operate on different priorities and timelines.

As a result, recovery often falls through organizational gaps.

A dedicated enforcement capability allows each group to contribute without ongoing overhead:

• Engineering provides access to operational data
• Finance receives quantified financial outcomes
• Leadership gains accountability insights

Financial Governance Implications​

Unrecovered credits are not just lost savings — they represent incomplete financial reporting.

Organizations benefit from auditable visibility into:

• Provider performance versus commitments
• Financial impact of outages
• Compensation received
• Outstanding entitlements
• Risk exposure from recurring failures

This information supports budgeting, forecasting, and vendor management decisions.

Vendor Accountability and Negotiation Leverage​

Historical performance data changes renewal conversations.

Instead of relying on marketing claims or aggregate statistics, organizations can reference:

• Actual delivered reliability
• Frequency and severity of incidents
• Effectiveness of compensation mechanisms
• True cost adjusted for outages

Independent verification reduces information asymmetry and strengthens negotiating positions.

Why Automation Is Essential​

At enterprise scale, outages are not rare events — they are routine occurrences across different services and regions.

Tracking eligibility manually requires continuous attention, specialized expertise, and cross-functional coordination.

Automation converts enforcement from a reactive activity into an ongoing operational process:

• Continuous monitoring against SLA definitions
• Detection of potential violations
• Quantification of financial impact
• Preparation of claim-ready evidence
• Tracking of submission deadlines and outcomes

A Natural Evolution of FinOps​

As the discipline matures, organizations move through stages:

1. Visibility — understanding where money goes
2. Optimization — improving efficiency of usage
3. Governance — aligning spend with business value
4. Assurance — ensuring contractual promises are honored

SLA enforcement sits squarely in the fourth stage.

It completes the financial control loop.

The True Cost of Downtime​

Outages impose multiple layers of impact:

• Lost revenue or productivity
• Incident response costs
• Customer dissatisfaction
• Reputational damage

While service credits rarely offset all losses, they represent the portion providers have agreed to share.

Failing to claim them shifts the entire burden to the customer.

Designing for Enterprise Reality​

Effective recovery solutions must respect common constraints:

• Strict security requirements
• Limited engineering bandwidth
• Complex account structures
• Multi-cloud environments
• Need for auditability

Deployment models that require minimal permissions and operational effort are essential for adoption.

Executive-Level Relevance​

Leadership increasingly asks:

• What financial exposure do outages create?
• Are we receiving compensation when commitments are missed?
• Which vendors deliver reliable value relative to cost?
• How resilient is our infrastructure portfolio?

Providing credible answers requires translating technical reliability data into financial terms.

Closing the FinOps Loop​

Cloud providers have matured their billing, monitoring, and support systems. Enterprises have matured their cost management practices.

What has lagged behind is enforcement.

Guarantees exist. Compensation mechanisms exist.
But without systematic recovery, they remain largely theoretical.

FinOps is ultimately about ensuring cloud spending aligns with business value.

Recovering entitlements when performance falls short is not a peripheral activity — it is a fundamental part of that mission.

Conclusion​

Organizations have invested heavily in understanding and optimizing cloud costs.

The next frontier is ensuring those costs accurately reflect delivered service.

True cloud cost management does not end with optimization — it ends with accountability.​

When providers meet their commitments, you pay as expected.
When they do not, financial responsibility should be shared according to the agreements already in place.

Closing that gap turns visibility into control and transforms FinOps from cost tracking into cost assurance.