Privacy / SIGSUG
SIGSUG — Privacy Policy
SIGSUG is a restaurant system that SFWD Studios is developing. This provisional version states what it processes today: the closing report for each service, sent via WhatsApp, and access to the app, which is still in testing.
Provisional version of September 30, 20261. Scope, version, and who processes the data
This policy applies to SIGSUG, a restaurant system in development. The data described here is processed by SFWD STUDIOS LTDA, registered in Brazil under CNPJ 68.097.694/0001-60, at Avenida Rio Branco, 311, Sala 609, Centro, Rio de Janeiro/RJ, Brazil, under the SFWD Studios brand.
This is a provisional version. It describes only what SIGSUG processes today and will be reviewed by a lawyer when the complete SIGSUG policies are published. Every change will carry a new date on this page. It does not cover the SFWD Studios website or the studio’s other products.
2. The closing report via WhatsApp
At the end of each service—the working period the restaurant opens and closes in the app—SIGSUG sends the closing report via WhatsApp: a summary with figures such as occupancy, table times, and revenue. The message comes from the SFWD Studios WhatsApp number.
The message goes only to the number indicated by the restaurant’s administrator in SIGSUG, and only after their consent is recorded. When consent is revoked, the messages stop. No data about the restaurant’s customers goes through WhatsApp: the message carries no customer’s name, phone number, ID number, or order.
The app does not yet have a screen to register or revoke the number. Today, our team registers it at the request of the restaurant’s administrator, and revocation can be requested by emailing contact@sfwdstudios.com (section 8).
The delivery status notices Meta sends also carry the destination number, and messages anyone writes to the SFWD Studios number reach our system through Meta. Neither the number in those notices nor those messages are read or stored. Replying to the closing report on WhatsApp therefore does not revoke the authorization: it can be revoked only by email.
3. What we process for this
To send the closing report and know whether it arrived, we process:
- the registered phone number;
- the consent record: the person at the restaurant who authorized the messages, the date of the authorization and, where applicable, the date it was revoked;
- the record of each send: whether and when the message went out, the attempts, the reason when it does not go out, and the identifier Meta assigns to it, which contains the destination number in encoded form;
- the delivery status Meta reports for each message—sent, delivered, read, or failed—with the time of each, the error code and title when it fails, and the pricing category Meta billed it under. Read status is reported only when the recipient keeps read receipts on in WhatsApp.
4. Purpose and retention
The data in section 3 is used to send the closing report to the restaurant’s administrator, know whether the message arrived, know how Meta billed each message, and prevent the closing report for the same service from being sent twice. We do not use this data for advertising. The functions that send the message and receive the delivery status do not write the number or the closing text to technical logs. The restaurant’s administrator and manager can see the status of each send, without the number.
The number is kept until the authorization is revoked. When the authorization is revoked, the registered number is deleted and no new message is sent to it. The dates of authorization and revocation remain as the record of consent. When the person stops being the restaurant’s administrator, the messages stop, but the number is deleted only upon revocation or a deletion request (section 8).
The send records and delivery statuses do not currently have a defined deletion period: they are kept with the restaurant’s history, and the period will be defined in the complete policy. The identifier of each message, which contains the number in encoded form, remains in that record after revocation, until a deletion request (section 8), which may also cover the rest of these records.
5. Who we share it with
We do not sell personal data. The data in this policy passes only through the providers below. Meta and GitHub process it outside Brazil; Supabase and Resend may process it outside Brazil. The mechanism for each international transfer will be described in the complete policy, after legal review; upon request, we will provide the information available.
- Meta, through the WhatsApp Business Platform, receives the destination number and the closing text, delivers the message, and reports its delivery status.
- Supabase hosts the database that holds the number, the consent record, and the record of each send, runs the functions that send the message and receive the delivery status, and provides the app’s authentication service (section 6).
- GitHub, through GitHub Actions, calculates each service’s closing report from the restaurant’s operating record (section 6) and stores in the database the text sent via WhatsApp. The phone number does not pass through it.
- Resend sends the app access code by email (section 6).
6. Access to the app
The SIGSUG app is in development and is used today only for testing, by the SFWD Studios team. There is no installation channel yet for anyone outside the studio.
To sign in, a person enters their email address and receives a six-digit access code, sent by Resend. Sign-in uses no password. The email address is kept in Supabase’s authentication service to identify the person at each sign-in. That service also processes technical data from each sign-in, such as the IP address, the device or browser, and the time.
The email address is also kept in the restaurant’s team record, with the name, the role, who registered the person and when, and each change of name, role, status, or email address. The restaurant’s team sees each person’s name and role; only the administrator and the manager see the email address and the history of changes.
The restaurant’s operating record—the floor plan, the tables, the orders, the closing report for each service, and the identifier of the device that recorded each action—belongs to the restaurant and will be covered by the complete SIGSUG policy before the app is offered to other restaurants.
7. Data-subject rights
Under Brazil’s LGPD, data subjects may request confirmation and access, correction, information about sharing, anonymization, blocking or deletion where applicable, portability within regulatory limits, objection, and withdrawal of consent.
The contact channel for data subjects is contact@sfwdstudios.com, for exercising a right or asking a question. We may request the minimum information needed to confirm identity and avoid delivering data to the wrong person. Data subjects may also petition Brazil’s National Data Protection Authority, without prejudice to other channels provided by law.
8. Data deletion
To request deletion of the data used for the WhatsApp messages, email contact@sfwdstudios.com with the phone number that receives the closing report. The restaurant’s administrator revokes the authorization the same way: the app does not yet offer this option.
Once the request is confirmed, we delete the registered number and the identifier of each message sent to it, which contains the number in encoded form, and stop sending the closing report to it. The dates of authorization and revocation remain as the record of consent.
The request may also cover the rest of the send records and the delivery statuses (section 3). We assess what can be deleted and state in our reply what was deleted and what remained, with the reason. Messages already delivered remain in the recipient’s WhatsApp, where they can be deleted in the WhatsApp app itself.
Requests about access to the app (section 6) go to the same address: we delete the access account and the email address kept in the team record. The restaurant’s operating record is not deleted, because each action stays recorded as it happened; it belongs to the restaurant and will be covered by the complete policy.
Backups and providers’ technical logs follow their own cycles and are not deleted at the same moment as the active data. We reply by email when the deletion is complete.
