Encryption
HTTPS with HSTS on every request and connector credentials encrypted with AES-256-GCM.
Trust Center
Security and privacy, in the open
If you trust Zizelo with your company's spend and access, you should know how they are protected. Here are the practices in place, in progress and coming next, each with its SOC 2 and ISO/IEC 27001 references and where it stands today. The page changes together with the code whenever a practice changes, and you can share it with your IT team, your legal team or a client who asks.
- practices in place
- 38
- in progress
- 3
- planned
- 10
Highlights
Access
Roles enforced on the server, isolation between companies and time-boxed, traceable support.
Transparency
An audit trail your company can see, including access by our own team.
Continuity
Verified daily backups, a backup before every release and automatic rollback.
Frameworks
We use the SOC 2 Trust Services Criteria (AICPA) and the ISO/IEC 27001:2022 Annex A controls as our guide. Each practice lists the matching controls, 31 SOC 2 criteria and 40 ISO references in total. Zizelo does not yet hold a certification or audit report; the mappings show how we are preparing for them.
Infrastructure and network
How the service is exposed to the internet and how the browser is protected.
Encryption in transit
In placeAll access to Zizelo uses HTTPS, with certificates issued and renewed automatically. The HSTS header makes browsers use a secure connection for one year, subdomains included.
SOC 2 CC6.7ISO 27001 A.8.20, A.8.24
Minimal network exposure
In placeThe server firewall only accepts SSH administration and web traffic (ports 80 and 443). The application only answers through the reverse proxy, and the database has no port published to the internet.
SOC 2 CC6.6ISO 27001 A.8.20, A.8.22
Security headers
In placeA Content Security Policy (CSP) restricted to our own domain, with explicit Google Analytics exceptions only on public pages, framing blocked against clickjacking, MIME sniffing protection and a strict referrer policy on every page.
SOC 2 CC6.6, CC6.8ISO 27001 A.8.26, A.8.27
External code limited by consent
In placeFonts and interface are local. Google Analytics only loads after statistics permission, to measure public pages and the sign-up funnel. Form and workspace data is not sent; URLs are limited to known routes without parameters or fragments. Without permission, there is no Google code loading or data transmission.
SOC 2 CC6.8, P6.1ISO 27001 A.8.26, A.5.34
Lean image, rebuilt on every release
In placeThe application runs in a container built from a minimal Node.js (Alpine) image. The image is rebuilt on every release, always pulling the latest base image.
SOC 2 CC7.1, CC8.1ISO 27001 A.8.8, A.8.9
Separate environments
In placeDevelopment, automated tests and production use separate databases, and tests only use fictitious data. Database resets refuse production databases, and development shortcuts, such as a fixed password reset code, never work in production.
SOC 2 CC8.1ISO 27001 A.8.31, A.8.33
External uptime monitoring
PlannedContinuous checks of the service from outside the server, with team alerts when something goes down.
Where it stands: Today the application checks itself every 5 minutes and publishes the result on the status page; the container checks health every 30 seconds, and every release is checked locally and over the internet.
SOC 2 CC7.2ISO 27001 A.8.16
Identity and access
Who gets in, how they prove who they are and what they can see or change.
Passwords protected with bcrypt
In placePasswords are stored only as bcrypt hashes, with a minimum of eight characters. Nobody on our team can read a user's password.
SOC 2 CC6.1ISO 27001 A.5.17, A.8.5
Secure sessions
In placeEach session uses a random 256-bit identifier in an httpOnly, Secure, SameSite cookie, valid for up to 30 days. Resetting the password ends every open session.
SOC 2 CC6.1ISO 27001 A.8.5
Abuse-resistant password reset
In placeA six-digit code sent by email, stored only as a hash, valid for 15 minutes and locked after five attempts. Requests are rate limited per account, the response never reveals whether an email is registered, and the person is notified when the password changes.
SOC 2 CC6.1ISO 27001 A.5.17, A.8.5
Roles enforced on the server
In placeEach workspace has one owner plus Admin, Specialist, Reader and Requester roles. Only the owner grants or removes the Admin role, transfers ownership and deletes the workspace; no Admin can change or revoke the owner. The Requester role, for people who only request purchases, is closed by default: it only reaches its own requests and tool names, and loses access when the person is offboarded. Every read and every change checks the person's membership and role on the server; the interface is never the only barrier.
SOC 2 CC6.2, CC6.3ISO 27001 A.5.15, A.5.18, A.8.3
Isolation between companies
In placeEach company has its own workspace. Every query is scoped to the user's active membership in that workspace, and a workspace address without membership answers as not found. Automated tests check this isolation on every release.
SOC 2 CC6.1ISO 27001 A.8.3
Verified sign-up
In placeNew companies sign up with an email on their own domain, with a valid mail server, and an active CNPJ checked against a public registry. Everyone else only joins by an admin's invitation.
SOC 2 CC6.2ISO 27001 A.5.16
Controlled, visible support access
In placeThe Zizelo team area is separate from the dashboard and has its own sign-in: it only accepts addresses on the team's corporate domain and, instead of a password, asks for a six-digit code sent by email, single-use and valid for 10 minutes, with limited attempts. A staff session lasts 12 hours, and the dashboard's password sign-in never opens this area. To diagnose a problem, staff can view the dashboard as the user for at most two hours, without accepting terms or invitations on their behalf. Every access and every change shows up in the workspace's own audit trail, visible to the customer.
SOC 2 CC6.3ISO 27001 A.8.2, A.5.15
API keys stored as hashes
In placeEvent API keys are stored only as hashes, and the full key is shown once, at creation. Internal scheduling endpoints require their own secret, compared in constant time, and notifications from our email provider are only accepted with a valid, recent signature.
SOC 2 CC6.1ISO 27001 A.5.17, A.8.5
Two-factor authentication (MFA)
PlannedA second sign-in factor through an authenticator app, with recovery codes, starting with workspace admins.
Where it stands: Today sign-in uses email and password.
SOC 2 CC6.1ISO 27001 A.8.5
Sign-in attempt limits
PlannedTemporary lockout after repeated password attempts, per account and per source, against brute-force attacks.
Where it stands: Limits already apply to password reset and to the staff code sign-in; the next step is applying them to password sign-in.
SOC 2 CC6.1, CC6.6ISO 27001 A.8.5
Data protection and privacy
What we store, how we protect it and for how long, under the LGPD (Brazil's data protection law).
Aggregate reports restricted to the team
In placeThe acquisition dashboard reads the Zizelo Google Analytics property's reports only after Google read authorization. The team session is checked on the server; the token is encrypted and never sent to the screen. The callback requires signed state, the same browser cookie and the same session, outside view-as mode. Reports are cached briefly in memory without identifying visitors or joining them to customer accounts.
SOC 2 CC6.1, P4.1ISO 27001 A.5.15, A.8.24
Encrypted connector credentials
In placeGoogle Workspace, Microsoft 365, Meta Ads, GitHub, Netlify, GoDaddy, Cloudflare, Anthropic, OpenAI and Cursor keys and tokens are encrypted with AES-256-GCM under a dedicated key, separate from the session key. They are never shown back (only the last four characters) and are deleted the moment the connector is removed.
SOC 2 CC6.1, C1.1ISO 27001 A.8.24, A.5.17
Read-only integrations
In placeConnectors only read and only talk to each vendor's fixed endpoints, with a timeout on every call. The one broader permission is Google Workspace licenses, which Google only offers as view and manage: Zizelo calls only the license read. When authorizing through Google, Cloudflare, GitHub or Netlify, the response is checked against a signed, short-lived value. For registrars, the requested permissions are read-only (domains.domain:read at GoDaddy, Registrar read at Cloudflare, by token or on its screen) and paging only follows the vendor's own addresses. On GitHub, only organization read access (read:org), with no access to repositories or code. Netlify offers no read-only permission: Zizelo only calls the team and plan reads. For AI providers (Anthropic, OpenAI and Cursor), the connector only accepts an admin key, only uses the cost and usage reports and sends the key in a header, never in the address.
SOC 2 CC6.6, CC9.2ISO 27001 A.5.23, A.8.26
Trends only from aggregated data
In placeParticipation in market trends is the owner's or an Admin's choice and can be turned off at any time. Only vendor, category, monthly amount and seats go in. A vendor only shows up with at least 5 different companies, company counts are shown in ranges and no specific company's amount is displayed. The panel only opens for participating workspaces with at least 10 contracts.
SOC 2 P4.1, C1.1ISO 27001 A.5.34, A.8.11
Data minimization
In placeFrom CSV statements we keep only the recurring charges we detect; every other row is discarded while reading. From ad accounts we read only monthly aggregate numbers, with no data about the people reached. From our own email events we keep type and time, with no IP or device data, and clicked links are stored without parameters. For an individual domain holder we keep only the type, with no name or CPF.
SOC 2 P3.1ISO 27001 A.5.34
Secrets kept out of logs and messages
In placeTokens, keys and authorization headers are stripped from error messages before anything is stored or displayed. The audit trail never stores passwords or credentials.
SOC 2 C1.1ISO 27001 A.8.11, A.8.15
Cookie consent by category
In placeWithout a choice, only strictly necessary cookies work. Interface preferences and analytics require permission, the choice is recorded on the account as proof and can be changed at any time. We use no advertising cookies.
SOC 2 P2.1ISO 27001 A.5.34
LGPD and versioned documents
In placePrivacy Policy and Terms of Use published in Portuguese and English, with versions and history. Acceptance is recorded on the account, and the dashboard asks for it again whenever a document changes.
SOC 2 P1.1, CC2.3ISO 27001 A.5.31, A.5.34
Your company owns its data
In placeThe customer company is the controller of its workspace data; Zizelo acts as processor. We do not use that data for advertising, do not sell it and do not build behavioral profiles. Export and deletion on request.
SOC 2 P4.1, P6.1ISO 27001 A.5.34
Short retention for access data
In placeSessions expire after 30 days. Reset codes last 15 minutes and are deleted after use. Database backups are kept for 14 days, and connector credentials are gone the moment the connector is removed.
SOC 2 P4.2, C1.2ISO 27001 A.8.10
Self-service export and deletion
In progressThe owner deletes the workspace and all its data from the danger zone in Settings, confirming with the workspace name; the deletion is kept in the platform log. Self-service export comes next.
Where it stands: Today export is handled on request.
SOC 2 P5.1, P4.3ISO 27001 A.8.10, A.5.34
Data protection officer and deletion period
In progressData protection officer (DPO) appointed: Renato Pacheco, renato@zizelo.com, published in the Privacy Policy. The period for deleting data after a contract ends is still to be set.
Where it stands: Deletion period being defined ahead of the commercial launch, together with the legal review of our documents.
SOC 2 P4.2, P8.1ISO 27001 A.5.34
Logging and monitoring
What gets recorded and who can see it.
Per-workspace audit trail
In placeEvery relevant change records who made it, when, through which path (manual, import, connector or API) and the before and after. The trail is available to the company itself, with search.
SOC 2 CC7.2, CC4.1ISO 27001 A.8.15
Staff activity log
In placeEvery action the Zizelo team takes in the admin area is recorded with author, date, target and the details of the change.
SOC 2 CC7.2, CC6.3ISO 27001 A.8.15, A.8.2
Release log
In placeEvery production release records the approved revision, the database backup taken beforehand and the result of the health checks.
SOC 2 CC8.1ISO 27001 A.8.15, A.8.32
Public status page
In placeThe status page shows each component's current state, a 90-day history measured every 5 minutes, incidents with updates until they close, and scheduled maintenance, which also appears in the dashboard up to 72 hours ahead.
SOC 2 CC2.3, CC7.4ISO 27001 A.8.16, A.5.26
Security alerting
PlannedCentralized server and application logs, with alerts for suspicious patterns such as spikes in failed sign-ins or API usage.
Where it stands: Today logs live on the server and in the audit trail, and review is manual.
SOC 2 CC7.2, CC7.3ISO 27001 A.8.16
Secure development and change management
How a code change reaches production.
Every change is tested before it ships
In placeType checking, unit tests, integration tests against a real database, a production build and end-to-end browser tests run on every change. Only an approved revision can be released.
SOC 2 CC8.1ISO 27001 A.8.25, A.8.29, A.8.32
Security rules covered by tests
In placeThe automated suite checks workspace isolation, read-only roles, credentials never shown back, password reset limits and support mode. This page is checked too: a test fails if a published control loses its reference in the code.
SOC 2 CC7.1, CC8.1ISO 27001 A.8.29
Controlled releases with automatic rollback
In placeThe server only releases the revision approved in CI, takes a verified database backup first, checks health locally and over the internet, and rolls back to the previous application version on its own if the new one does not respond.
SOC 2 CC8.1, A1.2ISO 27001 A.8.32
Server-side input validation
In placeForm and API data are validated on the server with typed schemas. CNPJs, emails, amounts and CSV files go through dedicated rules, covered by tests.
SOC 2 PI1.2ISO 27001 A.8.28
Pinned dependencies and restricted code access
In placeLibraries are installed from pinned versions. The server fetches code with a dedicated read-only key and verifies GitHub's identity against a pinned host key.
SOC 2 CC6.1, CC8.1ISO 27001 A.8.4, A.8.9
Secrets kept out of the code
In placeSession, encryption and external service keys live in server environment variables, outside the repository. In production, credential encryption refuses to run without a dedicated key of at least 32 characters.
SOC 2 CC6.1ISO 27001 A.8.9, A.5.17
Automated vulnerability scanning
PlannedContinuous dependency and code analysis in the repository, with assisted library updates.
Where it stands: Turn on dependency alerts and static code analysis on GitHub.
SOC 2 CC7.1ISO 27001 A.8.8
Independent penetration test
PlannedA yearly assessment by an external team, with a report summary available under NDA.
Where it stands: Planned after the commercial launch.
SOC 2 CC4.1ISO 27001 A.5.35, A.8.8
Continuity and incident response
Backups, recovery and incident response.
Verified daily database backups
In placeThe database is backed up every day, and each backup is checked before it is accepted. Backups are kept for 14 days.
SOC 2 A1.2ISO 27001 A.8.13
Backup before every release
In placeBefore any new version goes live, a verified database backup is taken so the previous state can be restored.
SOC 2 A1.2, CC8.1ISO 27001 A.8.13, A.8.32
Encrypted off-site backups
PlannedSending encrypted backups to storage separate from the production server, in another region.
Where it stands: Today backups are kept on the production server.
SOC 2 A1.2ISO 27001 A.8.13, A.5.30
Regular restore tests
PlannedFull restore of a backup in an isolated environment, with the time measured and the result recorded.
Where it stands: Each backup is already checked when created; the full restore routine is still to come.
SOC 2 A1.3ISO 27001 A.5.30, A.8.13
Incident response
In progressA procedure to detect, contain and report incidents, including notice to affected companies and to the ANPD (Brazil's data protection authority) under the LGPD.
Where it stands: The notification commitment is in our Privacy Policy; the written procedure, with owners and deadlines, is being drafted.
SOC 2 CC7.3, CC7.4ISO 27001 A.5.24, A.5.26
Governance and vendors
Policies, risk, vendors and contact channels.
Few, known vendors
In placeEvery external service that receives data is listed on this page and in our Privacy Policy, with its purpose and the data involved. The Google, Microsoft and Meta connectors are only used when a company turns them on.
SOC 2 CC9.2ISO 27001 A.5.19, A.5.23
Vulnerability disclosure channel
In placeAnyone who finds a flaw can write to our security contact, also published at /.well-known/security.txt following RFC 9116.
SOC 2 CC2.3ISO 27001 A.6.8
Security policy and training
PlannedAn approved information security policy, confidentiality agreements and yearly training for everyone with access to customer data.
Where it stands: Being drafted as the team is formed.
SOC 2 CC1.4, CC2.2ISO 27001 A.5.1, A.6.3, A.6.6
Yearly risk assessment
PlannedAn inventory of assets and risks, with prioritized treatment and a yearly review of the controls published on this page.
Where it stands: First formal assessment planned before the commercial launch.
SOC 2 CC3.2ISO 27001 cl. 6.1.2, A.5.9
Vendors that receive data
Subprocessors and external services involved in running Zizelo. The full list, with legal basis and international transfers, is in our Privacy Policy.
| Vendor | Purpose | Data | When |
|---|---|---|---|
| Google Analytics 4 | Public-page and sign-up funnel statistics | Public routes without parameters, allowed events, cookies and technical browser data | Only with statistics permission; may process outside Brazil |
| Resend | Email delivery, plus delivery, open and click events for relationship messages | Recipient name, email and message content | Always (United States) |
| BrasilAPI | Public CNPJ lookup | The CNPJ number entered | At sign-up and when creating a workspace |
| Registro.br · IANA RDAP | Public domain lookup | Registered domain names | When the domain connector is on |
| DNS público | Checking the email setup (MX, SPF, DKIM, DMARC) | Domain names registered in Domains | About once a week, for each registered domain |
| GoDaddy · Cloudflare | Reading the registrar account's domains (expiration, automatic renewal, lock, privacy) | The customer's own token or authorization on Cloudflare's screen, read-only; no personal data | Only when the company turns on the registrar connector |
| Netlify | Reading each team's plan, members and number of sites | The customer's own token (Netlify has no read-only permission; Zizelo only reads); no personal data | Only when the company turns on the Netlify connector |
| GitHub | Reading each organization's plan, seats and Copilot licenses | The customer's own token, organization read only; no personal data | Only when the company turns on the GitHub connector |
| Google · Microsoft · Meta | Reading licenses, users and ads | The customer's own credentials, read-only | Only when the company turns on the connector |
Found a vulnerability?
Write to our security contact with a description and the steps to reproduce it. Please do not access other companies' data or disrupt the service while testing. Anyone reporting in good faith will hear back about the fix, with our thanks.
Documents
Update history
Requester role, for people from the company who only request purchases and access. The role is closed by default on the server: every workspace page and action refuses the Requester except purchase requests, where they only see their own. When the person is offboarded, manually, by a connector or through the API, the access is revoked at once.
Netlify connector on Netlify's screen or with a personal token. Netlify offers no read-only permission; Zizelo only calls the team, plan, member and site-count reads, stores the token encrypted and checks the response against a signed, short-lived value.
GitHub connector on GitHub's screen or with a classic token, with organization read access only (read:org): plan, seats and Copilot licenses, with no access to repositories or code. The response is checked against a signed, short-lived value, and the token is stored encrypted.
Cloudflare on Cloudflare's own screen, as with Google: no API token or Account ID. The response is checked against a signed, short-lived value, the refresh token is stored encrypted and replaced on every use, and reading only reaches the domains registered in the accounts the person allowed.
New AI spend connectors (Anthropic, OpenAI and Cursor), read-only, with an encrypted admin key sent only in a header. Market trends with optional participation, aggregated data and a minimum of 5 companies per vendor.
Each workspace now has an owner. Only the owner grants or removes the Admin role, transfers ownership and deletes the workspace, always confirming with the workspace name and never in support mode. Deleting from the dashboard erases all workspace data and is kept in the platform log.
Domain registrar connectors: Registro.br through the public registry, no credential; GoDaddy and Cloudflare with a read-only company token, stored encrypted. GoDaddy paging only follows addresses on GoDaddy's own server, so the token never goes anywhere else. For an individual holder, only the type is stored.
Registered domains now have their email setup (SPF, DKIM and DMARC) checked in public DNS every week, with a warning in Opportunities when protection against fake messages is missing. Domains used in the company's emails but not in Domains become a suggestion to track.
Team acquisition dashboard with aggregate Google Analytics reports, a sequential funnel, encrypted read-only authorization and a callback bound to the same session. Reports are fetched by the server, without adding Google scripts or iframes to the admin area, identifying visitors or joining customer accounts.
The Google Workspace connector now reads each account's plan to estimate the cost per plan. Google only offers this reading within the view and manage licenses permission; Zizelo uses only the read call. From imported statements, we also keep the lines of inventory tools, for the payment history.
Google Analytics 4 limited to public pages and the sign-up funnel, only after consent. No form or workspace content, URL parameters or advertising; withdrawing permission deletes cookies and unloads the code. CSP allows only the required destinations on public routes.
Data protection officer (DPO) appointed: Renato Pacheco, renato@zizelo.com. The contact is in the Privacy Policy and handles data subject requests.
The Google Workspace connector can be authorized by any company account, with no key or token. Without administrator access, reading uses the company directory, also read only, with a safeguard that prevents offboarding more than half of the headcount at once. Personal Google accounts are rejected when the authorization returns.
The Zizelo team area now has its own passwordless sign-in: only addresses on the team's corporate domain, with a single-use code sent by email and a 12-hour session. Manual staff flagging no longer exists.
Public status page at /status, with automatic checks every 5 minutes, a 90-day history, incidents and scheduled maintenance announced in the dashboard. Checks from outside the server remain planned.
Delivery, open and click events for relationship messages now arrive through a signed Resend webhook, rejected without a valid signature. We keep only type, time and the link without parameters, with no IP or device data.
Trust Center launched, with practices in place and planned, mapped to SOC 2 and ISO/IEC 27001. Vulnerability disclosure channel published in security.txt.
Put your company's tools in order
See what renews in the next 60 days and where money is going to waste. Free up to 100 people, no credit card, for Brazilian companies with a work email and an active CNPJ.