Scoped security position
Zeph CMS contains meaningful security-oriented application controls. Final security and compliance statements depend on the actual Zeph-hosted environment, independent testing, providers, operations, contracts, customer configuration, and accepted evidence.
This page is not a penetration-test report, SOC report, ISO certificate, FedRAMP or StateRAMP authorization, formal CMMI appraisal, legal opinion, or blanket HIPAA/CJIS compliance statement. Framework mappings and repository self-assessments must be described as such.
The descriptions below identify control areas present in the product or active validation program. Each includes the evidence boundary that must be satisfied before an unqualified claim is made.
Password authentication, configurable MFA/TOTP, session and token controls, account lifecycle functions, and SAML/OIDC configuration paths exist in the application.
Validation boundary
Customer identity-provider behavior, MFA policy, break-glass access, logout, deprovisioning, rotation, and hosted configuration require environment-specific validation.
Role, permission, module-entitlement, office-scope, and protected-resource helpers are used across the application.
Validation boundary
Complete route/resource coverage, effective-permission proof, and two-office negative testing remain release and customer-scope evidence requirements.
The codebase includes encryption utilities, transport-security expectations, secret/configuration controls, and protected storage patterns.
Validation boundary
Actual provider configuration, key custody, rotation, recovery, encrypted-field coverage, backups, and logs must be verified in the Zeph-hosted environment.
Significant activity can be recorded through centralized audit helpers and integrity-oriented controls, including hash-chain support and legal-hold safeguards.
Validation boundary
Critical mutation coverage, sensitive-value handling, chain verification, office scope, retention, off-system evidence, and customer acceptance must be demonstrated.
File type, size, MIME/magic-byte, PDF/image, storage-key, access, quarantine, preview, download, and publication controls exist or are being validated.
Validation boundary
Fail-closed malware/quarantine behavior and equivalent production object-provider evidence are required across every applicable delivery path.
The repository includes automated governance, typechecking, regression tests, secret scanning, dependency/static-analysis workflows, release checks, and evidence artifacts.
Validation boundary
A successful build or automated scan is not an independent penetration test, certification, production authorization, or customer acceptance decision.
The applicable gates depend on the customer, data, licensed modules, integrations, providers, and executed scope.
Production-like Zeph-hosted architecture, provider, region, network, identity, key, database, object-storage, cache, and logging evidence
Current secret, dependency, static-analysis, and dynamic-testing results with findings disposition
Independent/manual penetration testing against the final production-like posture
Two-office authorization and public/sensitive response-contract proof for the applicable release
File scanning, quarantine, object-provider, preview/download, publication, and recovery evidence
Measured backup/restore, reconciliation, rollback, continuity, capacity, and incident-response evidence
Customer-specific SSO, integrations, claims/role mapping, network, monitoring, and vendor acceptance
Privacy, records, accessibility, legal/provider, insurance, support, and executed-contract completion
Customer security review, UAT, residual-risk disposition, and written go-live approval
Repository mappings may help organize control discussions for HIPAA, CJIS, NIST, ISO, and other frameworks. They are scoped self-assessments and do not establish certification or legal compliance.
SOC reports, ISO certification, FedRAMP/StateRAMP authorization, formal CMMI appraisal, penetration-test attestation, or similar assurance may be claimed only when current approved evidence actually exists.
Compliance and security outcomes depend on the complete customer and hosted operating environment, authorized use, data, policies, workforce, configuration, providers, contracts, and retained evidence.
Security responses should be based on the actual customer scope, hosted architecture, data, providers, integrations, contractual requirements, and current evidence—not generic percentages or badges.