Security Overview
We design for security by default: minimal data collection, least-privilege access, change control, and vetted vendors. This page summarizes our general controls and how to report a security issue.
2) Data handling (minimization, classification, retention)
- Typical data: contact details, support communications, project artifacts provided by the customer, and minimal operational logs.
- Sensitive data: we avoid processing sensitive categories by default (government IDs, biometrics, precise location, health data) unless explicitly required by contract and lawful basis is established.
- Retention: we retain information only as long as needed for service delivery, security, legal, or audit needs, then delete or de-identify where feasible.
3) Technical & organizational controls
| Area | Examples of controls |
|---|---|
| Encryption | TLS for data in transit; storage protections provided by our hosting vendors; secrets not committed to source control. |
| Access control | Least privilege, role-based access where supported, MFA for administrative accounts, session controls, and auditing where available. |
| Backups & continuity | Backups for critical assets where applicable; restore testing on a cadence aligned to the service and risk. |
| Hosting posture | HTTPS enforced, patching and configuration hardening, reduced attack surface for marketing pages; WAF/CDN options when appropriate. |
| Monitoring | Security and operational logs for investigation; anomaly review; retention limited to what’s necessary. |
| People & process | Confidentiality obligations, access reviews, and internal playbooks for support and engineering. |
Controls may vary by engagement and are refined over time.
4) Secure delivery lifecycle
- Peer review for meaningful changes; dependency updates and vulnerability monitoring where practical.
- Separation of environments (dev/stage/prod) when applicable; rollback planning for production changes.
- Secrets management outside source control; least-privilege credentials and rotation as appropriate.
- Privacy-by-design: collect minimum data, disable unused services, and limit access.
5) Vendors & subprocessors
We use vetted providers for functions like hosting, email, analytics (when enabled), support tools, and other infrastructure. Where a vendor may process personal information, we use contractual safeguards and publish our list at /legal/subprocessors.
6) Incident response
If we become aware of a security incident that materially affects customer data, we investigate promptly and notify impacted customers without undue delay where required by law or contract.
| Severity | Description | Typical actions |
|---|---|---|
| Low | Minor issue with limited impact; contained by defense-in-depth. | Log, remediate in standard cycle, document outcome. |
| Medium | Elevated risk or limited scope; investigation required. | Prioritized remediation; customer notice if relevant to their systems or data. |
| High | Confirmed compromise or material risk to customer data/service. | Containment, urgent remediation, customer notifications and coordination where applicable. |
7) Vulnerability disclosure
We welcome coordinated disclosure. Email Support@kavacorellc.com with: affected URL(s), steps to reproduce, impact, and your contact info.
- Use good-faith testing that avoids privacy violations, data destruction, and service disruption.
- Do not access customer data without explicit permission.
- Test only assets we own/control (or where you have authorization).
security.txt (recommended)
Publish at /.well-known/security.txt on your domain.
Contact: mailto:Support@kavacorellc.com
Policy: https://kavacore.ai/legal/security
Preferred-Languages: en
Canonical: https://kavacore.ai/.well-known/security.txt
Expires: 2026-10-01T00:00:00Z8) Website hardening (headers & CSP)
We enforce HTTPS and recommend modern security headers. The examples below are starting points. Content Security Policy (CSP) is powerful but can break chat/analytics/widgets unless you allow their domains.
Apache (.htaccess) example
# NOTE: Example only. Test in staging first.
# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# HSTS (enable only after confirming HTTPS everywhere)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Baseline hardening headers
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set X-Frame-Options "DENY"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
# CSP (tight baseline; expand for approved widgets)
Header set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; script-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests"Nginx example
# NOTE: Example only. Add inside your server {} block.
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "DENY" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# CSP (expand for approved third-party widgets)
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; script-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests" always;
If you add LiveChat, GTM/GA4, maps, or booking tools, update CSP to allow their domains for script-src, connect-src, and frame-src where required.
9) Contact
Security reports: Support@kavacorellc.com
Phone: +1-888-808-2683
Current status: No known active incidents