Information Security Program

1. Purpose

This document is the umbrella for the SemantiqWall security program. It says who is accountable, how risks are handled, how exceptions are approved and how the policy pack is kept current. The other documents in this pack (01 to 11) set the specific rules.

The pack describes what exists today. Anything not yet in place is written as a commitment with an owner and a target date, never as done.

2. Organization and roles

SemantiqWall is operated by ZapBrabo Technology, based in Goiânia, Brazil, and is expanding to the United States. Today the company is run by one person, the Founder (Murilo Martins), who holds every role below.

Limit we disclose: with one person there is no separation of duties at the infrastructure level. Compensating controls: every application change passes the automated test suite before release; every security-relevant action in the product is written to an append-only, hash-chained audit log; deploys finish with an audit-chain integrity check.

When staff join: before the first employee or contractor receives access, the Founder assigns the roles above in writing, and the personnel controls in policy 10 become mandatory (background check where lawful, confidentiality agreement, onboarding and training, access review and offboarding). Reviewing code written by someone else becomes mandatory from the first hire.

3. Status vocabulary used in this pack

• In place - implemented and verifiable in the code or on the server.
• In rollout - being implemented now; not yet relied on.
• Commitment - not in place; has an owner and a target date.

All commitments will be tracked in a single list, the security register (section 6), which the Founder reviews monthly once it exists; until then, the commitments in this pack are the list of record.

4. Risk management method

1. Identify - sources: this policy pack, the CAIQ self-assessment, vulnerability reports (policy 07), incidents (policy 05), supplier changes (policy 09) and any significant change to the product or infrastructure.
2. Rate - likelihood (1 low, 2 medium, 3 high) × impact (1 low, 2 medium, 3 high) on customer data confidentiality, integrity or availability. Score 6-9 = high, 3-4 = medium, 1-2 = low.
3. Treat - mitigate, transfer, avoid or accept. High risks need a mitigation with a target date; acceptance of a high risk must be written and dated by the Founder, with a reason.
4. Track - each risk and its treatment is an entry in the security register.
5. Review - monthly for open high risks, and fully once a year together with this pack.

The current top risks, all tracked as commitments in the relevant policies, are: single VPS without off-site backup (policy 06), no disk encryption at the VPS level (policy 02), a single administrator (this policy), no CI pipeline or automated dependency scanning (policies 03 and 07), and no independent penetration test (policy 07).

5. Policy exceptions

An exception is any time a rule in this pack cannot be followed.

• It is requested in writing (an entry in the security register) with: the rule, the reason, the risk, compensating controls and an expiry date (maximum 90 days, renewable).
• The Founder approves or rejects it. Once staff exist, the person requesting cannot approve their own exception.
• Emergency changes (policy 03) that bypass normal steps are recorded as exceptions within 2 business days.
• Expired exceptions are closed or renewed at the monthly register review.

6. Security register and evidence

The security register is a private, versioned document kept outside the public repository, listing: open risks, commitments (owner and target date), exceptions, supplier reviews, incidents and completed reviews. Evidence (screenshots, command output, test results) is attached with the date it was collected.

Commitment: create the register, seeded with the gaps and commitments of this pack and the CAIQ self-assessment (owner: Founder, target 2026-10-15). Until it exists, the commitments in this pack are the list of record.

7. Review and approval

• Every document in this pack is reviewed at least once a year and whenever a significant change happens (new hosting, new subprocessor, first hire, a serious incident, a new law that applies).
• Each review is recorded in the register with the date and what changed. A new version number is issued when content changes.
• Approval is by the Founder, shown in each document header.
• Policies are communicated by publishing them at the SemantiqWall Trust Center and, once staff exist, by having each person acknowledge them at onboarding and after each new version.

8. Audit and assurance

• Today: there has been no independent audit (no SOC 2, no ISO 27001) and no third-party penetration test. The CSA STAR Level 1 self-assessment (CAIQ v4.1) is the first structured assessment.
• Internal assessment: the first annual internal assessment is the CAIQ self-assessment run against the code and server on 2026-09-28. From then on, the Founder re-runs it once a year and gives each finding a corrective action, owner and target date. Commitment: record these findings in the security register, which does not exist yet (owner: Founder, target 2026-10-15; section 6); until then they are tracked as the commitments in this pack.
• Commitment: independent penetration test before enforcing blocking for an external customer, target 2027-03-31 (owner: Founder). An independent audit will be planned when customer contracts require it.

9. Register of laws, standards and commitments

Reviewed at least annually and on significant change.

Special interest groups (commitment, owner Founder, target 2026-10-31): subscribe to the CISA Known Exploited Vulnerabilities feed, CERT.br alerts, GitHub security advisories for our dependencies, and PHP, Laravel and PostgreSQL security announcements; record the subscriptions in the register.