Information Security Policy

This policy is approved by company management and owned by the Privacy Owner / Data Protection Contact, who is accountable for its content, its review and the evidence supporting each control. It is reviewed at least annually and after any material change to the architecture, the hosting model or the data categories processed.

• The policy is published publicly so that marketplaces, sellers and auditors can verify it without a request.
• Deviations require documented approval from the policy owner and a compensating control.
• Every requirement written with 'must' is mandatory; the platform is not operated in violation of a mandatory requirement.

• Every workstation used to administer the platform runs an anti-malware solution with real-time protection enabled and automatic signature updates — Microsoft Defender Antivirus on Windows devices.
• Automatic operating system updates are enabled; security updates must be applied without delay.
• Server workloads run as containers built from official, maintained base images and are rebuilt when the base image receives security updates.
• Personal devices without the controls in this section must not be used to access the production environment.

• Access to Protected Data is granted on a need-to-know basis and limited to the minimum privileges required by the role.
• The application exposes a single administrator account. Every route other than the sign-in page and the unauthenticated health check requires a valid session and redirects unauthenticated requests to sign-in.
• The session is a signed token stored in an HTTP-only cookie with SameSite protection, marked Secure in production, so client-side scripts cannot read it. Sessions expire after 1 day, or 30 days when the operator selects 'remember me'.
• Administrative credentials are provisioned through environment variables and are never shared over chat or e-mail.
• Access rights are reviewed at least annually, and immediately when a role changes or a person leaves. Removal is completed on the same day.
• Marketplace tokens are scoped to the accounts the seller authorised, and are revoked when the seller disconnects the integration.

• Dependencies are audited for known vulnerabilities using the package manager advisory database, and are updated on a recurring basis.
• Critical and high severity vulnerabilities affecting the production environment must be remediated within 7 days of confirmation; medium severity within 30 days; low severity at the next maintenance window.
• Framework and runtime versions are kept on maintained releases so that security fixes remain available.
• Code that touches authentication, authorization, tokens or Protected Data is reviewed before deployment, and the build must pass type checking and linting.
• Configuration changes to the production environment are applied deliberately, with a database backup taken before any schema change.
• Findings, remediation and the date of the fix are tracked in the project repository so that evidence is retained.

• A full database backup is taken before any schema change and on a recurring schedule.
• Backup files are stored outside the production server so that loss of the host does not imply loss of the backup.
• The restore procedure is documented and must be followed for any recovery, including the verification that the backup file is not empty before it is relied upon.
• Backups inherit the classification of the data they contain and are protected accordingly, including encryption at rest.

Suspected and confirmed security incidents are handled under the published Incident Response and Breach Notification document, which defines severity levels, response phases, notification deadlines and the reporting channel gianlucca.florencio@zeroholding.com.br.