Ensuring the Security of Your Data

Netice is built to securely ingest, structure, and deliver platform-reported app revenue data into customer-designated cloud environments. This Security Policy explains the security principles and controls Netice applies to protect customer data, credentials, and access to the Netice application.

This Security Policy complements our Terms of Service and Privacy Policy. It is intended to provide a practical overview of how Netice approaches secure data handling, access control, credential protection, and operational reliability.

Security Scope for Netice App Revenue Data Services

Netice’s primary service is the automated ingestion and delivery of platform-reported app revenue and related reporting data from supported sources such as app stores and, where available, supported ad monetization platforms. Netice standardizes and delivers this data into customer-designated destinations such as cloud warehouses and cloud storage environments.

These workloads typically involve business, reporting, and revenue data rather than sensitive personal data. Netice processes such data only as required to execute customer-configured integrations, deliveries, backfills, and re-runs. Netice does not provide accounting, tax, or audit services, and Netice outputs should be understood as a platform-reported reporting layer rather than final booked accounting revenue.

Core Security Measures

1. Encryption in Transit

• Netice uses encrypted transport protocols for data transmitted between the Netice application, supported source platforms, secret storage systems, customer destinations, and other supporting infrastructure.
• Where HTTPS or equivalent secure APIs are used, Netice requires transport-layer encryption to protect data integrity and confidentiality in transit.
• Connections to customer-designated cloud destinations are executed through secure, authenticated channels.

2. Encryption at Rest and Secret Storage

• Credentials, tokens, keys, and other secrets used by Netice are stored in managed secret storage such as Google Cloud Secret Manager and/or AWS Secrets Manager, rather than hardcoded in application code.
• Secrets stored in managed secret systems are protected with encryption at rest and access controls provided by those platforms.
• Where Netice uses transient processing or staging storage during execution, data is protected with strong encryption at rest where applicable.

3. Secure Authentication and Access Control

• Netice follows a least privilege approach for application access, service identities, and internal operations.
• Access to production systems, credentials, and customer-linked integrations is restricted to authorized processes and personnel with a legitimate operational need.
• Netice uses managed authentication systems for user access to the application and applies controls intended to prevent unauthorized account access.
• Customer access within the application may be segmented by organization, workspace, team, or role, as applicable to the product.

4. Third-Party Platform Credential Handling

• When customers connect third-party platforms such as app stores or supported monetization/reporting platforms, Netice uses vendor-supported authentication methods where applicable, such as OAuth, API credentials, or service credentials.
• Integration credentials are stored securely, access-controlled, and used only for executing the customer’s configured data flows.
• Credentials are not intentionally exposed in logs, UI surfaces, or source code.
• Netice is designed to request and use only the permissions reasonably required for the configured reporting access and delivery operations.

5. Secure Processing and Ephemeral Handling

• Netice is designed so that customer data is processed automatically as part of ingestion, normalization, and delivery workflows.
• Where transient staging or temporary processing is required, Netice aims to retain data only for as long as operationally necessary to complete the configured run, validate delivery, retry safely, or recover from errors.
• Temporary data created during processing is deleted or allowed to expire once it is no longer required for the execution workflow, subject to backup, logging, legal, and operational constraints.
• Under normal operations, Netice is designed to deliver data into the customer’s designated destination rather than retain it as a long-term hosted dataset inside the Netice application.

6. Output Integrity, Schema Safety, and Delivery Controls

• Netice is designed to deliver either source-native raw outputs or standardized enriched outputs, depending on customer configuration.
• Where Netice transforms platform data into structured tables or unified schemas, Netice applies validation and schema-handling controls intended to reduce risks such as silent column shifts, malformed output, or accidental corruption.
• Netice is designed to support retries, backfills, and re-runs so reporting outputs can be rebuilt when required.
• Deliveries to supported warehouses and storage destinations are executed through controlled service identities and authenticated connections.

7. Logging, Monitoring, and Operational Security

• Netice maintains operational logs and monitoring needed for security, stability, debugging, and service reliability.
• Logs are intended to focus on operational metadata, system events, failures, and execution status rather than customer report contents wherever reasonably possible.
• Security-relevant access to secrets, infrastructure, and production systems may be logged and monitored.
• Error handling is designed to help diagnose failures without unnecessarily exposing customer data content.

How Netice Handles Customer Data

Limited Purpose Processing

Netice processes customer data only for the purpose of providing the service requested by the customer, including ingestion, normalization, delivery, retries, backfills, customer support, security, fraud prevention, and compliance with legal obligations.

No Data Broker Behavior

Netice does not sell customer data. Netice does not act as a data broker and does not redistribute customer data to unrelated third parties for their independent commercial use.

No General Human Access in Normal Operations

Netice is designed so that customer data flows are handled automatically without routine human access to underlying report contents during normal operations. Where human access is exceptionally required for support, incident response, legal compliance, or security reasons, such access is intended to be limited, justified, and handled under appropriate controls.

Customer-Designated Destinations

Netice delivers data into destinations selected and controlled by the customer, such as supported cloud warehouses or cloud storage environments. Customers are responsible for the security configuration, permissions, and downstream governance of those destinations.

Application Security

Account and Session Security

• Netice uses managed authentication infrastructure for user sign-in and session handling.
• User passwords, where applicable, are stored using strong password hashing rather than plaintext storage.
• Session handling, token validation, and related controls are designed to reduce the risk of unauthorized access.

Web Security Controls

• Netice applies web application security controls intended to reduce risks such as cross-site scripting (XSS), cross-site request forgery (CSRF), injection, and unauthorized requests.
• Where applicable, Netice may use controls such as CSRF protection, content security policy (CSP), secure headers, and nonce-based script restrictions.
• Administrative and operational endpoints are intended to be protected through authentication and access control mechanisms appropriate to their function.

Payment Security

Netice uses third-party payment infrastructure such as Paddle for payment processing where applicable. Payment card details are processed by the payment provider under its own security and compliance controls rather than being stored directly by Netice.

Compliance and Privacy Commitments

GDPR

• Netice aims to follow data minimization principles and process personal data only as necessary for legitimate service, security, contractual, and legal purposes.
• Where required by applicable law, users may request access, correction, deletion, or other rights described in our Privacy Policy.
• Where cross-border data transfers occur, Netice may rely on appropriate legal transfer mechanisms where required.

CCPA / CPRA

• Netice does not sell personal information.
• Where applicable, eligible users may exercise access, deletion, and other rights described in our Privacy Policy and applicable law.
• Netice may take reasonable steps to verify the identity of requestors before fulfilling privacy-related requests.

Customer Responsibility

Security is a shared responsibility between Netice and the customer.

• Customers are responsible for: securing their own source-platform accounts, destination environments, IAM permissions, tax/accounting interpretations, dashboard logic, downstream data sharing, and internal access governance.
• Customers should use least-privileged credentials, protect their own administrator accounts, review destination permissions carefully, and promptly revoke credentials that are no longer needed.
• Netice allows customers to rotate their credentials.

Policy Updates

Netice may update this Security Policy from time to time to reflect changes in the product, infrastructure, legal requirements, or security practices. Material changes will be published on the relevant policy page.

Your Trust Matters

Netice is built for a high-trust use case: business-critical revenue reporting data that teams rely on for finance and analytics. We take that seriously. Our aim is not only to move data, but to do so in a way that is controlled, secure, and operationally reliable.

For more information, please refer to our Privacy Policy and Terms of Service.