Security Controls and Data Protection Statement
July 15, 2026
Qualense uses layered application and infrastructure safeguards appropriate to its current stage. This statement is not a certification, audit report, penetration-test result, or promise that every control operates effectively in every environment.
1. Current service boundary
The reviewed product consists of a web frontend and a backend API with evidence storage, PostgreSQL data, identity, AI-provider integrations, assessment workflow, exports, and logging. Production AWS infrastructure is defined in infrastructure-as-code but had not been deployed and operationally verified as of the date above. Any statement about the live service must be rechecked after deployment.
Qualense does not currently accept CUI or classified information. It is not represented as FedRAMP authorized, FIPS validated, SOC 2 certified, CMMC certified, or as fully implementing NIST SP 800-171.
2. Controls evidenced in application code
| Domain | Current evidenced behavior | Limitation / verification needed |
|---|---|---|
| Authentication | OIDC integration designed for Amazon Cognito with authorization-code flow and PKCE; application sessions use HTTP-only cookies; production configuration requires secure cookies. | Verify deployed identity configuration, MFA policy, recovery, lockout, lifecycle, and privileged administration. |
| Session/CSRF | SameSite=Lax cookies, anti-CSRF middleware, and an eight-hour sliding session are configured. | Validate cross-origin behavior, timeout expectations, logout/revocation, and end-to-end tests in production. |
| Authorization | Workspace-scoped access checks and Member/Admin roles are implemented on reviewed paths. | Complete endpoint-level authorization tests and periodic tenant-boundary testing. Two roles may be insufficient for some customers. |
| Rate limiting | Stricter limits exist for authentication and public form submissions. | Tune for production traffic, distributed deployment, abuse patterns, and alerting. |
| Transport/browser protection | Production HSTS and headers including no-sniff, frame denial, no-referrer, and cross-origin opener policy are configured. | Confirm TLS termination, certificate lifecycle, CSP needs, and an external header scan after deployment. |
| Upload integrity | File size/type policies, SHA-256 integrity metadata, short-lived pre-signed transfers, archive limits, and processing states are implemented. | Verify storage policy and race/failure behavior in production. File-type allowance is not proof that content is safe. |
| Malware/CUI/secret screening | Screening services and quarantine/delete paths exist; images and image-only/sparse PDFs are stopped before external AI processing; a ClamAV deployment is designed. | ClamAV, storage deletion, native-text classification, and failure behavior require deployed verification. CUI remains prohibited. |
| Provenance | Original customer evidence is distinguished from system-generated output; generated output is not intended to become independent source evidence. | Validate all import/export and re-upload paths. |
| Audit | Security and workflow events are recorded with a hash-chain design intended to expose tampering. | Database permissions, external retention/WORM export, monitoring, chain verification, and incident use are not yet operationally proven. Do not claim immutable logs. |
| AI governance | Provider operations, model usage/cost metadata, workspace mapping consent, human review workflow, cost caps, and a pre-AI visual-content gate are present. | Confirm consent coverage for every supported external-provider path and retain the governing provider contracts/settings. |
| Scoring and review | Deterministic calculations use approved assessment state; score-affecting support requires an approved, eligible mapping with a valid exact citation to the current evidence version. Verifier disagreement requires an attributed override reason, and unknown SSP consistency routes to review. | Catalog source completeness and deployed end-to-end verification remain release gates. |
| Health/operations | Liveness/readiness endpoints and production-oriented configuration checks exist. | Monitoring, alerts, on-call ownership, runbooks, and live SLOs require deployment and rehearsal. |
3. Production infrastructure designed but not yet verified
The infrastructure code describes AWS networking, private/isolated subnets, ECS/Fargate services, encrypted S3 storage, encrypted Multi-AZ PostgreSQL, 14-day database backups, Cognito, SES, Systems Manager/secret handling, load balancing, logging, and malware-scanning components. These are intended controls, not current assurances until:
- the correct AWS account and region are confirmed;
- deployment completes without insecure substitutions;
- policies, encryption, keys, public-access blocks, security groups, and secrets are inspected;
- recovery, backup restoration, scaling, failure, and deletion are tested;
- monitoring and response owners are active; and
- evidence is retained for the review.
Frontend production hosting and its security configuration must also be documented; it was not established by the reviewed infrastructure plan.
4. Data protection practices
Qualense intends to minimize provider payloads, scope access to authorized workspaces, separate original and generated records, screen uploads, use encryption in transit and at rest in deployed AWS services, record important actions, and use contracted subprocessors. Customer Content should not be used to train Qualense's own general-purpose models without separate explicit permission.
External AI processing and retention are described in the AI Data Handling and Subprocessor Disclosure. Anthropic and Voyage are reported as business accounts; the executed terms and training/retention settings still require documentary verification. Individual evidence deletion now removes all stored versions through the configured storage adapter and redacts content-bearing application records. Designed S3 buckets expire noncurrent versions after 30 days and access logs after 90 days. Full account/workspace purge, generated-output cleanup, backup handling, restore-and-redelete, provider requests, and deployed verification remain unresolved.
5. Security operations still required
Before customer-data use, Qualense should establish and test:
- named security and privacy ownership with an incident contact;
- vulnerability/dependency management and patch timelines;
- secret rotation and privileged-access review;
- centralized alerts for authentication, tenant-access, upload, malware, provider, export, audit-chain, and cost anomalies;
- incident-response, breach-notification, and prohibited-data playbooks;
- backup/restore and disaster-recovery exercises with measured results;
- retention, hard deletion, account purge, and offboarding;
- independent application and cloud security testing proportionate to risk;
- vendor due diligence, DPAs, training/retention settings, and change review; and
- secure development, change approval, release evidence, and rollback procedures.
6. Customer security responsibilities
Customers must classify data before upload; keep CUI and prohibited data out; control users, roles, devices, networks, exports, and credentials; configure permitted AI use; review output; report suspected incidents promptly; and preserve authoritative compliance records. Qualense controls do not secure the customer's environment or implement the customer's NIST requirements.
7. Claims Qualense must not make
Unless later supported by current independent evidence, Qualense must not claim:
- CMMC certification or guaranteed CMMC readiness;
- FedRAMP authorization or "FedRAMP High LLMs";
- FIPS 140-2 or FIPS 140-3 validation;
- SOC 2 certification or audit completion;
- complete NIST SP 800-171 implementation across the stack;
- "military-grade" security;
- immutable or tamper-proof logs;
- automatic 30-day deletion or cryptographic erasure from all backups; or
- 24/7 monitoring, a 24-hour response SLA, zero retention, or no-provider-training without verified terms.