Security & Privacy

1. Core principles

• Integrity: Records are designed to remain traceable and make later changes detectable (e.g., via checksums/references, depending on setup).
• Confidentiality: Access to protected areas is role- and permission-based. Data access follows a “need-to-know” principle.
• Availability: Operations aim for stable availability, traceable deployments, and fast incident handling.
• Data minimization: We process and store only what is necessary to provide the service. Scope and details depend on features and usage.

2. Access control & roles (RBAC)

Account and administrative access is handled through authentication and session management. Organization permissions are role-based (RBAC). Sensitive actions (e.g., issuing/updating/revoking records, bulk import, integrations) are validated server-side and protected against unauthorized execution.

3. Transport & communications security

Data in transit is typically protected via TLS. For integrations (e.g., API/webhooks), authentication and signature mechanisms may be used depending on setup (e.g., API keys/secrets, webhook signatures). Concrete technical details may vary by hosting/setup.

4. Data & document storage (off-chain)

Documents/attachments (e.g., PDFs) are typically stored off-chain and linked via references. Access is controlled by permissions; public verification pages are designed with data minimization so only what’s required for verification context is shown. Depending on setup, time-limited access methods or token-based retrieval may be used.

5. Logging, audit trail & abuse prevention

Technical logs (e.g., server logs) may be generated for troubleshooting, stability, and attack detection. In addition, an audit trail of relevant actions may be maintained (e.g., issuance, status changes, bulk imports, webhook deliveries) to support traceability and abuse detection. For personal data processing details, see the Privacy Policy.

6. Integrity, verification & blockchain references

Certifylize may use technical integrity mechanisms such as cryptographic checksums (hashes), references, and—depending on the use case—blockchain anchoring. Important: verification is a technical consistency/integrity check and does not replace legal or regulatory review. Security levels (e.g., S1–S4) may provide different protection and evidence features depending on configuration.

7. Responsibilities (issuer/verifier)

Customers/issuers are responsible for the content they include in records/certificates and metadata (e.g., product data, documents, statements, validity), and for running compliant processes where personal data is involved. Verifiers should request additional evidence in critical cases. Certifylize provides the technical platform, verification pathways and integration interfaces.

8. Reporting security issues

If you believe you found a security issue, please contact us at support@certifylize.com. Please do not send sensitive data unencrypted.