// scope
This page is the public summary of our security posture. Detailed control documentation, our subprocessor list, our incident-response procedure, and our business-continuity posture are linked from here. Specific commitments on an engagement are governed by the MSA, SoW, DPA, and SLA.
Last updated: August 16, 2026
1. Our posture
We treat security as an ongoing engineering responsibility, not a certification. Controls are selected for the system, the data, and the risk involved, then revisited as the system and the threat model change. We document the trade-offs openly and we tell you where we are not the right vendor (see our regulatory coverage).
2. Baseline controls
Secure transmission
Production traffic is served over HTTPS only. Internal service-to-service traffic is encrypted with mTLS where supported, and certificates are rotated automatically.
Limited access
Access to production systems and customer information is granted on least privilege, with short-lived credentials, hardware-key MFA, and audit logging.
Layered delivery checks
Code review, automated tests, dependency and secret scanning, and deployment gates reduce avoidable production risk. We treat production changes as code, not as ad-hoc commands.
3. Secure transmission
All production traffic between your browser and our services is encrypted in transit using TLS 1.2 or higher. Internal service-to-service traffic in our managed environments is encrypted with mTLS where the platform supports it, and certificates are managed by an automated rotation pipeline.
4. Limited access
Access to production systems and customer information is granted on a least-privilege basis. Personnel with administrative access use hardware-key MFA and short-lived credentials issued by a central identity provider. Production access is logged, and logs are retained per our incident-response procedure.
5. Layered delivery checks
Code review is required for every change to a system that holds customer data. Automated checks include unit and integration tests, static analysis, dependency and known-CVE scanning, and secret scanning. Deployments are gated by the automated checks and by an approval on the change. Sovereign-tier engagements add a customer approval before the change goes to production.
6. Data protection
We minimize the information collected for a task, use managed platforms with native encryption at rest, and avoid putting credentials or secrets in source code. Where a customer engagement requires additional controls, including encryption with a customer-managed key, a specific data-residency region, a BAA, or a DFARS clause. those requirements are agreed as part of the SoW and documented in the runbook.
7. Responsible disclosure
If you believe you have found a security issue affecting empowered.guru, please do not exploit it or access anyone else's data. Send a clear description and reproduction steps to security@empowered.guru. Our Responsible Disclosure Policy explains the process, scope, and our good-faith safe harbor.
8. Incident response
Our incident-response procedure, including customer notification commitments, is published at /legal/incident-response. For personal-data incidents, the DPA controls.
9. Questions about an engagement
Security requirements vary by product. If you need to discuss architecture, compliance needs, or delivery controls for an engagement, start with our contact page or email security@empowered.guru. We will respond within 2 business days and can issue a security questionnaire response within 5.