ShogramVerify before you buy or use.

Privacy and data use

Your privacy matters

Read how this draft describes information used to operate Shogram, what still needs confirmation, and where the final policy will be published.

Document status

Draft for review

Effective date

31 October 2026

Reading time

About 10 minutes

This is a draft, not an active Privacy Policy

The legal identity, legal bases, service providers, retention periods, transfer details and privacy contact still need confirmation. Bracketed text marks unresolved information.

At a glance

What this draft covers

A navigation aid to the draft, not a separate statement of approved practice.

Information and use

Draft categories and purposes for accounts, verification, reports and Company workflows.

Sharing and transfers

Provider names, countries and transfer safeguards still require production review.

Retention and security

Retention periods and live operational controls must be confirmed before approval.

Rights and contact

The request process, privacy contact and country-specific rights need legal review.

Draft document details
Version
[VERSION]
Last updated
[DATE]
Who this draft covers
Visitors, Guests, Registered Users, Companies, Owners, Staff, administrators and other people whose information is processed through the Platform
Review note
Initial data-category draft based on the inspected application schema and request flows. Provider, legal-basis, retention, transfer and contact details remain unresolved.
Privacy contact
Not finalized in this draft

Shogram / Privacy

Privacy Policy

Effective 31 October 2026 · Privacy contact: Support@shogram.com

Draft for review. This Policy is not effective. The data controller, lawful bases, recipients, international transfers, retention periods, child-user rules and rights process must be verified by the privacy owner and qualified counsel for [COUNTRY/LAW] before publication. This draft describes categories found in the application; production configuration and actual operational collection must still be checked.

In plain words

Shogram processes information to operate accounts, check Shogram Codes, protect the service, review Company applications, handle Reports and support billing where enabled. Scan location is optional and requires consent in the audited API. Reports may include optional photos and location. Companies submit business and KYC information. The precise providers, legal reasons for processing, retention periods, international transfers and privacy contact have not yet been confirmed. We do not sell or share personal information for unrelated purposes under this draft; the final policy must be confirmed against production integrations and law.

1. Who is responsible

The proposed controller/operator is [COMPANY LEGAL NAME], of [ADDRESS]. Data protection contact: [DPO EMAIL]. These placeholders must be replaced with verified details before this Policy is published. The legal identity of any Company that independently collects information through its own Products or business remains that Company’s responsibility.

This Policy applies when you use the Shogram website, consumer service, Company workspace, verification service, or related support and security processes. A Company may give you a separate notice for information it collects outside Shogram.

2. Information the Platform processes

The following categories were identified from the application’s data models, database migrations and request flows. The production owner must confirm that each category is enabled, identify any fields not listed here, and remove any category that is not collected.

Person or activity Information categories found in the application
Website visitor Request/session information needed to serve pages and protect the service; the web server or deployment may process network and browser metadata. Exact server-log fields and duration require hosting review.
Consumer verification Account and device identifiers; submitted Shogram Code or its internal reference; verification time and outcome; Product/Company/Batch references where matched; request IP may be processed by the service; optional coordinates only when supplied with location consent.
Consumer account Name, email address, password hash, email-verification state and timestamps, account/security state, preferences such as locale and notification choices, and linked devices. Authentication flows may also process password-reset, email OTP, MFA and recovery information; secrets should be stored in protected or hashed form as configured.
Scan and verification record Code, Company, Product and Batch references; Result and reason; device and, where applicable, account association; source and timestamp; optional consented latitude/longitude rounded by the verification API; country/city fields where available; IP and user-agent hashes in audit/security records.
Consumer Report Report reference; category and description; optional shop name; account or device association; related scan, Code, Product and Company references where available; Report status; optional location coordinates; attached evidence files and their file metadata. The audited API accepts photo attachments subject to its validation limits.
Company and its users Business/trading and legal names; registration number; country; tax ID where provided; contact name, email and phone; address; website; industry/category and Product information; account identifiers, roles and permissions; email-verification, security and KYC status.
KYC and Company documents Submitted incorporation, trademark and other requested documents; original filename, storage path/reference, MIME type, size and file hash where recorded; review status and related Company/user identifiers. These documents may contain personal information about owners or representatives.
Products, Batches, Labels and Codes Product names/descriptions, categories, variants, images or specifications where entered; Batch identifiers and date/status fields; Code and label design/validation records; print/export job metadata where those modules are enabled. Do not upload unnecessary personal information into these records.
Billing Plan and subscription references; payment provider name; internal and provider payment references; amount, currency, status and checkout/session metadata. The Company’s contact email may be sent to the configured payment provider. The Platform does not need to receive a full card number for the described hosted checkout flow; confirm the exact provider integration before publication.
Security, audit and administration Actor, Company, action, affected entity, entity identifier, selected before/after values, event timestamps, IP/user-agent hashes, integrity hashes, authentication/session state, rate-limit/security events and relevant support/review decisions. The application’s session store may include a user identifier, IP address and user-agent depending on deployment configuration.
Preferences and browser storage Locale and notification preferences are stored for a Registered User. Theme preference may be stored in browser storage. Session and CSRF cookies or equivalent session/security storage may be used. Exact browser storage and lifetimes belong in the Cookie Policy and require production inspection.

The public demo contact form does not submit a support message. A support channel, if enabled, may collect your contact details and the message or attachments you choose to send. Its actual fields and provider must be disclosed before that channel is activated.

The Platform may process the categories above to:

  1. create and secure accounts, verify email and authenticate users;
  2. receive a Code request, return a Result, maintain the related scan record and support a user’s scan history;
  3. review Company identity information and documents and control account access;
  4. receive, route, investigate and record user Reports;
  5. operate subscriptions and initiate or reconcile payments where checkout is configured;
  6. prevent abuse, protect Codes and accounts, investigate security events, maintain audit records and keep the service reliable;
  7. respond to a valid legal request, exercise or defend legal claims, or meet another legal duty; and
  8. remember settings and provide the requested interface.

The lawful basis for each purpose depends on [COUNTRY/LAW] and the parties’ roles. A qualified privacy lawyer must complete the following mapping before publication: [LAWYER REVIEW: purpose-by-purpose legal basis, including consent for optional location and any sensitive identity/KYC information]. This draft does not assert a particular statutory basis.

4. Location and device information

The audited verification API accepts latitude and longitude only when location consent is provided and rounds the coordinates to two decimal places before creating the verification request. A Report may also include location when the user chooses to include it. Location should be optional where the feature permits. The live interface, device permission prompts, stored precision, access and retention must be confirmed before publication.

The service may associate a signed-in consumer’s activity with a device identifier to support account continuity and abuse prevention. The exact identifier generation, reset and retention behavior must be confirmed. Do not describe a device identifier as a person’s real-world identity.

5. Reports and attachments

A Report is a user submission and is not a verified finding. It may contain the description, category, shop name, optional location and photos selected by the user. The Report may be linked to a related scan or Company if the information is available. Avoid including unrelated people, identification documents or private details in a Report.

The Company access rules for Report details and reporter identity must be confirmed against production APIs, roles, webhooks and notifications before publication: [PRODUCT/PRIVACY REVIEW: exact Company visibility and disclosure exceptions]. No promise is made here that Companies can or cannot see a particular field until that review is complete.

6. Who may receive information

Information may be accessed by authorized personnel who need it to operate the Platform, review a Company application, handle a Report, investigate security or meet a legal obligation. Access should be limited by role and purpose and logged where the system supports it.

The Platform may use service providers for hosting, email or OTP delivery, payment processing, file storage, monitoring or support if those providers are configured. The exact provider names, services, locations and contractual roles are not confirmed by this audit and must be listed here before publication: [SERVICE PROVIDER, PURPOSE, COUNTRY, DATA SHARED].

For a payment you initiate, the configured checkout provider may receive information such as Company name/contact email, payment amount, currency, plan, internal reference and transaction details. The provider’s own notice also applies to its processing.

Information may be disclosed to a regulator, law-enforcement agency, court or other party only where a valid legal basis or process requires or permits it, or where necessary to protect a person, the Platform or legal rights. The process, review authority and user-notice rules require [COUNTRY/LAWYER REVIEW].

The application audit did not confirm advertising or data-broker integrations. Production integrations and server logs must be checked before making a public statement about sale, advertising, analytics or third-party sharing. [PRODUCTION REVIEW REQUIRED]

7. International transfers

Hosting, email, payment and storage providers may process information in countries outside your own. The locations, transfer safeguards and any required notices must be confirmed for the live deployment: [COUNTRIES, RECIPIENTS AND TRANSFER SAFEGUARDS — privacy/counsel review]. No transfer destination is asserted by this draft.

8. Retention

The Platform retains information only for an approved period and purpose. No complete, approved retention schedule was found during the audit. The following table must be completed with the privacy owner and engineering before publication; do not leave the placeholders unresolved.

Information Proposed retention rule Status
Account profile and preferences While the account is active, then [PERIOD/DELETION RULE] Decision required
Device identifiers and account scan history [PERIOD OR INACTIVITY RULE] Decision required
Scan records and verification audit [PERIOD] Decision required
Reports, attachments and review records [PERIOD AFTER CLOSURE] Decision required
Company KYC documents [PERIOD AFTER ACCOUNT/REVIEW ENDS] Decision required
Products, Batches, Labels and Code status [PERIOD AND POST-SUBSCRIPTION RULE] Decision required
Payment references and accounting records [PERIOD REQUIRED BY COUNTRY/LAW] Decision required
Security/audit logs and session records [PERIOD BY LOG CATEGORY] Decision required
Backups and deleted-account data [BACKUP CYCLE AND FINAL DELETION PERIOD] Decision required

Some information may be retained longer where needed to meet a legal duty, investigate a security incident, resolve a dispute or protect a one-time Code status. Any such exception and its duration must be specified in the final retention schedule. See [Data Retention and Deletion Policy — route pending].

9. Security

The application includes role and Company scoping, password hashing through the authentication framework, MFA checks for privileged Company/admin actions, private handling of Company documents, and hashed IP/user-agent values in some audit records. The application also has security headers and integrity fields for audit events. These are implementation observations, not a guarantee that every deployment, integration or device is secure.

The operator must verify the live configuration, access reviews, encryption/key handling, backup controls, incident response and provider safeguards before publication. Do not include exploitable technical details in this public Policy. Report a suspected vulnerability using [SECURITY CONTACT] once that channel is verified.

10. Children

The minimum age for use, parental permission requirements, handling of children’s information and process for addressing a child’s account have not been approved. [LAWYER REVIEW: age and child-protection obligations in each launch country]. Until this is resolved, do not claim that the Platform is designed for or knowingly collects information from children.

11. Your privacy rights and choices

Depending on [COUNTRY/LAW], you may have rights to request access, correction, deletion, restriction, objection, portability, withdraw consent or complain to a regulator. The exact rights, limits, identity checks, response times and request-handling process must be confirmed by counsel.

To make a request, contact [DPO EMAIL] or use [PRIVACY REQUEST ROUTE — pending]. You may also use account settings for export or deletion where those features are available. A request may need verification to protect your information. Some information may be retained where law permits or requires it, including records needed for security, legal claims or Code integrity. Explain the specific reason if a request cannot be fully completed.

12. Cookies and similar storage

The Platform may use session and security storage, including cookies or equivalent mechanisms, to keep a session and protect requests. It may also remember interface preferences using browser storage. Exact names, purposes, duration and any third-party technologies must be documented in the [Cookie Policy — route pending] after production inspection. This draft does not confirm analytics or advertising cookies.

13. Complaints and changes

For a privacy question or request, contact [DPO EMAIL]. If you remain dissatisfied, you may contact the competent privacy regulator for [COUNTRY]: [REGULATOR NAME AND CONTACT — counsel to verify]. Do not treat the placeholder as an active address.

We may update this Policy through a documented version and notice process. The notice period, delivery method and renewed-consent requirements depend on the nature of the change and [COUNTRY/LAW]. Effective versions should be available at [LEGAL VERSIONS ROUTE — pending].

Contact and complaints

Controller: [COMPANY LEGAL NAME]
Address: [ADDRESS]
Support: [SUPPORT EMAIL]
Data protection contact: [DPO EMAIL]
Privacy request route: [PRIVACY REQUEST ROUTE]
Regulator: [COUNTRY / REGULATOR — qualified counsel to complete]

How to complain

Contact [DPO EMAIL] with the issue and the account or Report reference needed to locate it. Do not send passwords or full payment credentials. If the matter is not resolved, use [EXTERNAL REGULATOR/COMPLAINT ROUTE — to be completed for each country]. A privacy complaints process and response time must be approved before publication.

Change log

Version Date Summary
[VERSION] [DATE] Initial data-category draft; controller, bases, providers, transfers, retention and rights process require review.

Questions about privacy?

Contact the Shogram team

Use the Contact page for general support. Do not send passwords, one-time codes, identity documents or sensitive personal details through a public message.