How Netice keeps your data secure
Security policy of Netice Platform

Last updated: August 14, 2026

Netice Oy (“Netice,” “we,” “us,” or “our“) provides software for ingesting, structuring, and delivering platform-reported app-business data into customer-designated cloud environments. This Security Policy explains the security principles, technical and organizational measures, shared-responsibility boundaries, and vulnerability-reporting rules that apply to the Netice Data Transfer Platform and related hosted services that link to this Policy (collectively, the “Services“).

This Policy complements the Netice Terms of Service (the “Terms“), Privacy Policy, any applicable data processing agreement (“DPA“), order form, and other written agreement between Netice and the customer. Capitalized terms not defined in this Policy have the meanings given in the Terms or applicable written agreement.

No internet-connected system can be guaranteed to be completely secure. Netice applies risk-based safeguards intended to protect the confidentiality, integrity, availability, and resilience of the Services, but this Policy is not a guarantee that security incidents, errors, interruptions, or unauthorized activity can never occur.

1. Status and Legal Effect of This Policy

This Policy is a public, high-level description of Netice’s security approach as of the date stated above. It is intended to help customers understand the general controls and responsibility boundaries relevant to the Services. It is not an exhaustive description of every control, configuration, system, vendor, threshold, procedure, or risk.

  • Informational document. Unless a written agreement expressly incorporates a specific provision of this Policy, this Policy does not create a separate contractual warranty, service-level commitment, indemnity, fiduciary duty, audit right, or other obligation beyond the Terms, applicable DPA, order form, and applicable law.
  • No certification or audit opinion. This Policy is not a SOC report, ISO certification, PCI attestation, independent technical-assessment report, legal opinion, regulatory approval, or independent assurance statement.
  • Control flexibility. Netice may modify, replace, supplement, or retire controls as threats, technology, providers, law, and the Services evolve. Netice may use alternative controls that provide materially similar or stronger risk reduction.
  • Configuration differences. Security features may differ by service, integration, plan, deployment, customer configuration, feature status, provider capability, or applicable written agreement. A feature visible in documentation or code is not necessarily enabled or generally available to every customer.
  • Priority of documents. If this Policy conflicts with a signed order form, DPA, or other written agreement, that signed agreement controls to the extent of the conflict. Otherwise, the Terms and Privacy Policy control over this Policy.
  • Security-sensitive omissions. Netice may withhold exact infrastructure topology, endpoint details, identifiers, software versions, detection logic, rate limits, network rules, access paths, incident evidence, or operational runbooks where disclosure could increase risk, violate law, reveal confidential information, or impair the security of Netice, a customer, or a third party.

2. Scope and Service Boundaries

2.1 In-Scope Services

This Policy applies to the hosted Netice Data Transfer Platform, the application interfaces and APIs made available for that platform, and the Netice-operated processing used to execute supported app-business data tasks, including account and workspace administration, saved connections, task configuration, first runs, recurring refreshes, backfills, re-runs, status reporting, and delivery to supported customer-designated destinations.

2.2 Out-of-Scope Systems and Activities

Unless a written agreement expressly states otherwise, this Policy does not govern or guarantee the security of:

  • Apple, Google, Paddle, cloud providers, data warehouses, object-storage providers, identity providers, email providers, analytics providers, or any other third-party service;
  • a customer’s source-platform account, destination account, network, endpoint, browser, device, identity system, administrator account, user conduct, downstream application, dashboard, data model, export, backup, or data-sharing practice;
  • data after it has been delivered to a customer-controlled destination, except to the limited extent Netice retains access needed to perform a configured task;
  • unsupported, modified, reverse-engineered, self-hosted, preview, beta, experimental, legacy, or third-party integrations unless expressly included in a written agreement;
  • Netice consulting services or separately contracted work that does not expressly incorporate this Policy; or
  • security failures caused by customer instructions, excessive permissions, insecure destination configuration, compromised customer credentials, unlawful data, third-party outages, force majeure, or activity outside Netice’s reasonable control.

2.3 Shared Responsibility

Security is a shared responsibility. Netice is responsible for security controls within the portions of the hosted Services that Netice operates and controls. Customers remain responsible for their users, credentials, source and destination accounts, access grants, data classification, lawful processing, destination regions, downstream use, and any systems they operate or select.

3. Data and Accounting Boundaries

3.1 Typical Service Data

The Services are designed principally for business, reporting, operational, and platform-reported app revenue data. Depending on the selected workflow, the Services may process daily app-sales reports, monthly platform finance reports, source-native report artifacts, app and product identifiers, transaction categories, reporting periods, currencies, amounts, source metadata, destination configuration, task metadata, and operational status information.

3.2 Separate Reporting Semantics

Daily app-sales reporting, monthly platform finance reporting, and provider-native raw reports are separate data products with different source semantics, availability windows, and intended uses. Access to one report family does not prove access to another report family. A missing, delayed, unavailable, or unsupported report must not be interpreted as zero activity or final financial truth.

3.3 Not an Accounting, Tax, Audit, or Legal System

Netice processes and delivers platform-reported data. Netice does not originate the underlying source data and does not independently guarantee its accuracy, completeness, legal character, payout status, accounting treatment, or fitness for any financial statement. Unless expressly agreed in writing, Netice does not provide accounting, audit, tax, legal, fiduciary, assurance, bank-reconciliation, or regulated financial services. Netice output is not a substitute for a customer’s books and records, internal controls, professional judgment, reconciliation, or compliance process.

3.4 Restricted and Sensitive Data

The Services are not designed, intended, or marketed for the processing of Restricted Data unless Netice has expressly agreed in a signed written agreement. “Restricted Data” includes, without limitation:

  • special categories of personal data under Article 9 of the GDPR;
  • protected health information, medical records, genetic data, or regulated health data;
  • biometric identifiers used for identification;
  • government-issued identification numbers, social-security numbers, passport numbers, or comparable identifiers;
  • full payment-card numbers, card verification codes, magnetic-stripe data, PINs, or other cardholder data requiring a PCI cardholder-data environment;
  • online-banking credentials, private consumer financial-account credentials, or similarly sensitive authentication material unrelated to a supported integration;
  • criminal-history data, precise location data, children’s data, or data subject to sector-specific restrictions that the Services are not contractually configured to support;
  • classified information, export-controlled technical data, state secrets, or data whose processing through the Services is prohibited by law or contract; and
  • any other data designated as prohibited or restricted in the Terms, product documentation, or an applicable written agreement.

Credentials legitimately required to connect a supported source or destination are not prohibited merely because they are sensitive; those credentials are subject to the credential protections described below. Customers must not place Restricted Data in task names, support messages, logs, metadata fields, or other fields not designed for such data.

3.5 No General Duty to Inspect Customer Data

Netice may use automated validation, abuse-prevention, harmful-content, integrity, or policy controls, but Netice does not undertake a general duty to inspect, classify, monitor, or verify all Customer Data. The customer remains responsible for determining whether its data is permitted and appropriate for the Services. Netice may reject, quarantine, delete, suspend, or restrict processing when it reasonably suspects prohibited, unlawful, malicious, or unsafe data or activity.

4. Security Principles

Netice’s security approach is based on the following principles:

  • Least privilege. Access should be limited to the permissions reasonably needed for the relevant task, service identity, administrator, or support purpose.
  • Server-side authority. Authentication, tenant context, role, subscription state, secret ownership, task ownership, and destination authorization are determined or verified server-side rather than trusted solely from browser input.
  • Defense in depth. Netice uses multiple layers of preventive, detective, and recovery-oriented controls rather than relying on a single safeguard.
  • Fail-closed behavior. Where a security-critical identity, entitlement, credential, destination, or runtime verification cannot be completed reliably, the intended behavior is to deny, pause, or safely fail rather than silently grant access or continue an unsafe write.
  • Data minimization. Netice aims to process and retain only the data reasonably needed to provide, secure, support, and improve the Services and to meet legal obligations.
  • Write-only credential handling. Stored secret values are not intended to be displayed back through normal application interfaces after saving.
  • Customer-owned output. Under normal operation, the durable business-data output is delivered to the customer’s selected warehouse or storage environment rather than maintained as a general long-term hosted analytics dataset inside Netice.
  • Bounded diagnostics. User and administrative diagnostics are designed around safe statuses, counts, reason categories, windows, and integrity signals rather than raw report contents or credential material.
  • Controlled change. Security-relevant changes are version-controlled and subjected to review, testing, release controls, or verification appropriate to their risk.
  • Continuous adaptation. Controls, thresholds, providers, and procedures may be updated in response to new threats, vulnerabilities, operational evidence, and product changes.

5. Encryption and Secure Transport

5.1 Encryption in Transit

  • Netice uses encrypted transport protocols, such as HTTPS/TLS or the secure protocol supported by the relevant provider, for communications between supported browsers, the Netice application, source platforms, secret storage, background services, and supported customer destinations.
  • Connections to customer-designated cloud destinations are made through authenticated provider interfaces or protocols appropriate to the selected integration.
  • Netice may reject, disable, or decline configurations that require an insecure or unsupported protocol.
  • The customer is responsible for securing any customer-controlled endpoint, certificate, domain, network, proxy, SFTP server, role trust policy, warehouse endpoint, or storage configuration.

5.2 Encryption at Rest

  • Netice uses managed cloud services and storage mechanisms that provide provider-supported encryption at rest for persisted service data where applicable.
  • App integration credentials and other approved application secrets are stored in managed secret storage with encryption at rest and access controls.
  • Temporary files, staging objects, task metadata, logs, and backups may be protected through different provider-managed mechanisms appropriate to their service and risk.
  • Customer-managed encryption keys, dedicated keys, hardware security modules, single-tenant encryption boundaries, or a specific cryptographic configuration are not included unless expressly stated in a written agreement.

5.3 Cryptographic Flexibility

Netice may update protocols, cipher configurations, key-management methods, certificate providers, or encryption services as standards and provider capabilities change. This Policy does not guarantee support for a particular protocol version, algorithm, key length, or customer-managed key model unless expressly agreed in writing.

6. Credentials, Keys, and Secret Storage

6.1 Managed Secret Storage

At the date of this Policy, app integration secrets are stored using Google Cloud Secret Manager. Netice may replace or supplement this service with another managed secret-storage system that provides materially similar or stronger protections.

  • Raw credentials are not intended to be hardcoded in public source code, ordinary task records, browser-visible configuration, or public documentation.
  • Task and saved-connection records are designed to persist opaque references and safe connection metadata rather than plaintext app secrets.
  • Runtime secret access is performed server-side and is intended to validate the relevant tenant, purpose, provider, and task context before use.
  • Decrypted credentials may exist briefly in process memory when necessary to authenticate to a source or destination. Netice does not represent that encrypted credentials can be used without ever being decrypted in authorized runtime memory.

6.2 Write-Only Credential Boundary

  • Normal user interfaces are designed not to reveal stored private keys, access keys, passwords, tokens, service-account files, passphrases, or internal secret references after saving.
  • Connection cards and task interfaces may display safe metadata such as provider type, status, masked identifiers, creation or rotation time, authorization method, or verification result.
  • Customers must retain any recovery material that a provider requires. Netice is not a credential escrow, password manager, or guaranteed recovery service.

6.3 Credential Rotation, Replacement, and Deletion

  • Where supported, customers may rotate or replace connection credentials without Netice displaying the prior secret.
  • Deletion of a saved connection may be blocked while active or retained tasks still reference it.
  • Deleting a Netice connection or secret copy does not necessarily revoke the underlying provider-side API key, service account, role trust, OAuth grant, public key, user, or other authorization. The customer must revoke provider-side access in the relevant provider console or system.
  • Secret versions, backup copies, security evidence, or deletion records may remain for a limited period where needed for rollback, fraud prevention, legal compliance, incident investigation, reference integrity, or provider backup operation.
  • Netice may reject concurrent, ambiguous, excessive, or unsafe credential rotations and may require reauthentication or additional verification.

6.4 Customer Credential Obligations

Customers must use dedicated, least-privileged credentials where possible; must not share personal administrator credentials unnecessarily; must rotate credentials when exposure is suspected; must remove access when no longer needed; and must promptly notify Netice of suspected compromise. Customers are responsible for the accuracy and lawful authority of every credential they provide.

7. Identity, Account, Session, and Access Security

7.1 Managed Authentication

  • Netice uses managed identity infrastructure for user authentication and account session handling.
  • Where password authentication is used, password processing is handled through the managed identity provider’s controls. Netice does not intentionally store user passwords in plaintext.
  • Netice validates authentication tokens or sessions server-side and may use revocation-aware verification, expiry, reauthentication, logout, session renewal, or step-up controls where supported and appropriate.
  • Multi-factor authentication may be available, optional, required, or unavailable depending on account type, provider support, configuration, role, risk, and deployment. This Policy does not promise that every account has the same MFA method.

7.2 Session Protection

  • Session cookies and tokens are configured with security attributes and lifetime controls appropriate to the deployment.
  • Netice may expire, revoke, refresh, or invalidate sessions after inactivity, logout, credential changes, suspected compromise, account suspension, administrative action, or a security event.
  • Customers must not share sessions, tokens, cookies, login links, recovery codes, or authentication factors.
  • Customers must use supported browsers and devices, keep them updated, and protect them against harmful software, unsafe extensions, local compromise, and unauthorized physical access.

7.3 Administrative and Internal Access

  • Production access is restricted to authorized personnel and processes with a legitimate operational, support, security, or legal need.
  • Administrative actions may require stronger authentication, separate access paths, additional policy checks, or security logging.
  • Netice does not provide routine human access to underlying customer report contents during normal automated processing.
  • Exceptional human access may occur when reasonably necessary for support, customer-authorized troubleshooting, security response, abuse investigation, legal compliance, service recovery, or protection of Netice, customers, or third parties.
  • Netice may refuse a support request that would require unsafe credential sharing, excessive access, or disclosure of another customer’s information.

8. Workspace and Tenant Isolation

  • Netice derives the active workspace, organization, tenant identifier, role, and relevant entitlement from authenticated server-side records and policy rather than treating browser-supplied tenant or paid-status fields as authoritative.
  • Tasks, saved connections, credential references, and relevant operational records are intended to be scoped to the active customer workspace.
  • Role-based controls distinguish owners, editors, viewers, or other roles supported by the Services. Mutating or connection-management actions may be limited to authorized roles.
  • Unknown, inactive, inconsistent, or ambiguous organization membership or role states may be normalized to a lower-privilege state, denied, or blocked pending resolution.
  • Netice may prevent unsafe ownership changes, workspace exits, task moves, or connection reuse where the action could orphan tasks, bypass billing ownership, cross workspace boundaries, or create ambiguous access.
  • No tenant-isolation mechanism eliminates all risk. Customers must manage invitations, role assignments, account offboarding, shared provider credentials, and destination permissions carefully.

9. Application, API, and Abuse-Prevention Controls

Netice applies application-security and abuse-prevention controls appropriate to the relevant route, request, user, machine identity, and risk. These controls may include:

  • authentication and authorization checks;
  • server-side tenant, role, subscription, task, connection, and ownership validation;
  • cross-site request forgery protection and origin or referer validation for applicable mutations;
  • content security policy, framing restrictions, referrer controls, browser-isolation headers, and other secure response headers;
  • input validation, output encoding, identifier validation, type checking, and rejection of malformed or unsupported values;
  • request-body, form-memory, upload, field-count, and request-size limits;
  • rate limits, quotas, concurrency limits, retry limits, task ceilings, saved-connection ceilings, provider-call limits, queue controls, and other cost- or resource-abuse safeguards;
  • bounded error responses and suppression or redaction of raw internal exceptions;
  • machine authentication for internal, scheduled, administrative, or background-worker endpoints;
  • application-integrity or attestation controls where supported;
  • idempotency keys, replay resistance, distributed locks, claim checks, and duplicate-delivery handling;
  • anti-automation, trial-abuse, fraud, IP, account, device, behavioral, or risk-based controls, subject to the Privacy Policy;
  • blocklists, deny rules, temporary holds, reauthentication requirements, and session revocation; and
  • security tests intended to prevent the reintroduction of known high-risk patterns.

Netice does not publish exact security thresholds or detection logic. Limits may vary, may be changed without notice, and are not a purchased capacity or service commitment unless expressly included in an order form.

9.1 Fail-Safe Errors

Security-sensitive errors are intended to provide enough information to support legitimate use without exposing secrets, raw stack traces, internal identifiers, customer data, or attack-enabling detail. Netice may return generic errors, bounded reason codes, or require support verification instead of revealing the precise internal cause.

9.2 Protective Intervention

Netice may automatically or manually rate-limit, reject, challenge, delay, pause, quarantine, revoke, block, suspend, or terminate requests, sessions, tasks, connections, users, organizations, IP addresses, integrations, or provider calls when Netice reasonably believes the activity is abusive, unsafe, unlawful, compromised, misconfigured, costly, disruptive, or inconsistent with the Terms. Netice may take urgent protective action without advance notice where delay could increase risk.

10. Source and Destination Access Controls

10.1 Provider-Supported Authentication

Netice uses authentication methods supported by the relevant source or destination where available. Depending on the integration, this may include OAuth, API credentials, service credentials, managed service identities, cross-account roles, private-key authentication, or other provider-supported methods.

10.2 Least-Privilege and Recommended Modes

  • Netice is designed to request or recommend only the permissions reasonably required for the selected reporting and delivery workflow.
  • Where supported, managed identities, scoped roles, or key-pair authentication may be preferred over reusable long-lived passwords or broad administrator credentials.
  • Source access and destination access are separate security boundaries. A credential used to read a source must not be assumed to authorize writes to a destination, and a destination credential must not be assumed to authorize source access.
  • Customers must follow the current setup instructions and must not grant broad release-management, billing-administration, identity-administration, account-administration, or unrelated data access merely for convenience.

10.3 Target Verification

  • Task setup selects the specific destination target, such as a project, dataset, table, bucket, prefix, database, schema, stage, or comparable resource.
  • Netice may validate the format, ownership, availability, and permitted scope of the selected target before or during execution.
  • Where a reusable credential has broader provider permissions, Netice may still enforce a narrower task-specific target in application logic.
  • Verification is not a guarantee that the customer’s provider-side IAM is optimal, that another principal cannot access the target, or that the target is legally or operationally appropriate.

10.4 Provider Changes and Failures

Third-party providers may change APIs, schemas, authentication requirements, report availability, rate limits, permissions, file formats, or service behavior without Netice’s control. Netice may pause, modify, or discontinue an integration where continued operation is unsafe, unlawful, unsupported, or commercially unreasonable.

11. Data Processing, Staging, and Retention

11.1 Automated Processing

Customer Data is generally processed automatically to retrieve supported source reports, normalize or preserve data according to the selected workflow, validate candidate output, and deliver it to the customer’s selected destination.

11.2 Transient and Staging Data

  • Netice may temporarily stage, cache, decompress, parse, transform, validate, hash, compare, or otherwise process source data as necessary to execute a task.
  • Temporary data may be retained long enough to complete a run, retry safely, investigate a failure, prevent duplicate processing, validate delivery, support recovery, enforce integrity controls, or meet legal and security requirements.
  • Temporary data is deleted, overwritten, or allowed to expire when no longer reasonably required, subject to provider behavior, backups, logs, incident evidence, legal holds, and operational constraints.
  • Netice does not promise immediate or forensic erasure from all backups, replicas, caches, or provider systems.

11.3 Service Metadata

Netice may retain account, organization, task, connection, schedule, status, billing, security, fraud-prevention, support, audit, and operational metadata for longer than transient report data when reasonably needed to provide the Services, enforce the Terms, maintain records, prevent abuse, resolve disputes, comply with law, or protect Netice and its users. Retention details for personal data are described in the Privacy Policy and applicable DPA.

11.4 Support Data

Customers must not send passwords, private keys, access tokens, session cookies, full credential files, Restricted Data, or unnecessary raw report contents through support forms or email. Netice may redact, quarantine, or delete unsafe support content. A support message may be retained as a business, security, or legal record even after the underlying task is deleted.

11.5 Termination and Deletion

  • Deletion of a Netice account, task, or connection does not automatically delete data already delivered to a customer-controlled destination.
  • The customer is responsible for deleting destination data and revoking provider-side grants.
  • Netice may retain limited records after termination for billing, tax, legal, dispute, fraud-prevention, abuse-prevention, security, backup, or legitimate business purposes.
  • Where a signed DPA or order form provides specific return or deletion terms, that document controls.

12. Customer-Owned Destinations and Shared Responsibility

Netice is designed to deliver supported outputs to customer-designated cloud warehouses or object-storage environments, such as supported configurations of BigQuery, Snowflake, Google Cloud Storage, or AWS S3.

  • The customer owns or controls the destination account and is responsible for its IAM, region, encryption configuration, retention, lifecycle rules, backups, network restrictions, public-access settings, downstream access, and regulatory suitability.
  • Netice cannot prevent a customer administrator, another customer-authorized principal, a destination provider, or a compromised customer account from accessing or altering data in the destination.
  • The customer must not configure a public bucket, public table, overly broad role, shared administrator account, or unrestricted destination merely because Netice can technically write to it.
  • Customers must review destination logs, permissions, cost controls, data-residency settings, and lifecycle policies.
  • Netice is not the customer’s backup provider unless expressly agreed in writing. Customers must maintain backups or recovery mechanisms appropriate to their business needs.
  • Netice may refuse or pause a destination that fails verification, uses unsafe identifiers, conflicts with another managed target, or creates an unacceptable risk of data loss or cross-task interference.

13. Output Integrity and Safe Delivery Controls

Security includes protection against unauthorized or unintended alteration. Depending on the workflow and destination, Netice may use controls such as:

  • schema validation and explicit handling of unsupported or unknown fields;
  • source-aware and report-family-aware processing;
  • candidate staging before a managed destination update;
  • duplicate-key checks and ambiguity guards;
  • window-scoped, period-scoped, provider-scoped, or source-scoped replacement rather than unrestricted destructive writes;
  • managed-target ownership or conflict checks;
  • idempotency, run claims, locks, retry controls, and duplicate-delivery no-ops;
  • manifest, hash, count, schema, or post-write verification where applicable;
  • protection against empty or invalid candidate data erasing trusted output where the workflow supports such a guard;
  • backfills, re-runs, or recovery workflows; and
  • bounded review summaries and warning codes.

These controls reduce risk but do not guarantee that source data is complete, correct, timely, non-duplicative, free of provider errors, or appropriate for a particular downstream decision. Customers must validate outputs before relying on them for material financial, legal, regulatory, tax, operational, or investment decisions.

14. Logging, Monitoring, Diagnostics, and Redaction

14.1 Operational Logging

Netice maintains logs, metrics, status records, alerts, and diagnostics reasonably needed to operate, secure, troubleshoot, support, and improve the Services. These records may include timestamps, status, route or action categories, counts, durations, provider categories, destination categories, bounded reason codes, security events, configuration posture, and sanitized identifiers.

14.2 Data Minimization and Redaction

  • Routine logs and persisted diagnostics are intended to avoid raw provider rows, full report contents, private keys, passwords, tokens, full credential files, session cookies, and other secret material.
  • Customer-facing and administrative review surfaces are intended to expose safe metadata rather than app identifiers, product identifiers, customer amounts, currencies, full source file names, full destination names, or secret references where those details are not required.
  • Netice applies redaction and safe-error controls to common credential and token patterns.
  • Redaction is a risk-reduction control, not a mathematical guarantee that no sensitive fragment can ever appear in a third-party exception, customer-submitted field, provider response, support message, or unforeseen error.
  • Customers must not place secrets or Restricted Data in task names, labels, free-text fields, filenames, object paths, table names, or support messages.

14.3 Security Monitoring

Netice may monitor authentication, authorization, secret access, administrative actions, task execution, unusual activity, abuse indicators, provider failures, destination posture, and system health. Monitoring may be automated, sampled, delayed, or provider-dependent. This Policy does not promise continuous human monitoring, a specific detection time, or prevention of every attack.

14.4 Log Retention and Disclosure

Log retention varies by record type, provider, operational need, risk, and law. Netice may preserve security-relevant records for investigation or legal purposes. Netice will not provide one customer’s logs, identifiers, evidence, or incident data to another customer except where legally required or expressly authorized.

15. Secure Development and Change Management

Netice applies development and release practices proportionate to the risk of the relevant change. These practices may include:

  • version control and traceable changes;
  • review of directly affected authentication, tenant, role, subscription, secret, task, scheduler, logging, and destination-write paths;
  • unit, integration, regression, static, browser, or deployment tests;
  • security-focused tests for tenant boundaries, secret redaction, request limits, token handling, secure headers, destination guards, and known dangerous patterns;
  • synthetic test data rather than real customer credentials or report rows;
  • dependency, configuration, and vulnerability review based on risk and available evidence;
  • release candidates, deployment gates, environment-specific configuration, source or artifact verification, and rollback procedures where appropriate;
  • least-privileged runtime identities and restricted infrastructure permissions;
  • feature flags, staged enablement, safe defaults, or fail-closed configuration for higher-risk capabilities; and
  • post-deployment validation, monitoring, or corrective action.

No development process eliminates all defects. A passing test suite, code review, automated check, or deployment check does not prove the absence of vulnerabilities, undiscovered provider behavior, configuration mistakes, or future supply-chain issues.

15.1 Vulnerability and Dependency Handling

Netice evaluates known vulnerabilities and security findings according to factors such as practical risk, exposure, affected data, tenant impact, available mitigations, provider status, and operational risk. Netice may remediate, mitigate, isolate, disable, accept, or monitor a risk based on that assessment. Not every automated-tool finding represents an actionable vulnerability, and Netice does not commit to a fixed remediation deadline unless required by law or a signed agreement.

16. Infrastructure, Service Providers, and Payment Security

16.1 Cloud and Service Providers

Netice relies on third-party infrastructure and service providers for functions such as cloud hosting, storage, identity, secret management, queuing, monitoring, communications, and billing. Those providers operate under their own security, availability, privacy, contractual, and compliance programs.

  • Netice selects and configures providers based on operational, security, product, legal, and commercial considerations.
  • Netice may change providers, regions, architectures, or subprocessors subject to applicable law and contract.
  • A provider’s certification, audit report, or compliance status does not automatically certify Netice or extend the provider’s attestation to the entire Services.
  • Provider outages, security incidents, API changes, regional restrictions, account actions, or service limitations may affect Netice.

16.2 Payment Security

Where applicable, Netice uses Paddle or another third-party payment provider to process checkout, payment, tax, subscription, and billing functions. Full payment-card details are entered into and processed through the payment provider’s controlled checkout environment rather than intentionally stored by Netice as raw card data. Netice may receive limited billing and transaction metadata needed to manage subscriptions, support, accounting, fraud prevention, and legal obligations.

Customers must use the payment provider’s secure interfaces and must not send full card numbers or card verification codes to Netice through support, email, task fields, or other application inputs.

16.3 Third-Party Links and Integrations

Links, SDKs, APIs, and integrations with third parties do not make Netice responsible for those parties’ security or conduct. Customers must independently review and accept third-party terms, permissions, data-residency choices, and security settings.

17. Availability, Resilience, Backups, and Recovery

  • Netice uses monitoring, retries, re-runs, backfills, idempotency, locking, provider-follow-up, or recovery controls where appropriate to the workflow.
  • Netice may perform planned maintenance, emergency maintenance, migrations, security updates, provider changes, or temporary feature suspension.
  • Availability depends on Netice systems, third-party providers, source-report availability, customer permissions, destination capacity, network conditions, and customer configuration.
  • No uptime, recovery-time, recovery-point, support-response, data-durability, or business-continuity commitment applies unless expressly stated in a signed order form or service-level agreement.
  • Backups, snapshots, or replicas may be maintained for operational or security purposes, but they are not a substitute for customer-controlled destination backups.
  • Netice may restore from a known safe state, disable a compromised component, rebuild infrastructure, rotate credentials, re-run tasks, or require customer action following an incident or failure.
  • Customers must plan for source-provider delays, destination outages, credential expiry, API changes, and temporary interruption.

18. Security Incident Response and Notification

18.1 Definition

For this Policy, a “Security Incident” means a confirmed unauthorized acquisition of, access to, use of, alteration of, or disclosure of Customer Data or credentials in Netice-controlled systems that materially compromises their confidentiality, integrity, or availability. A Security Incident does not include, by itself:

  • unsuccessful or blocked attempts, denied requests, denied logins, or other events that do not result in confirmed compromise;
  • customer or third-party activity using valid credentials without evidence that Netice caused the authorization;
  • events limited to a customer-controlled source, destination, device, network, account, or downstream system;
  • availability interruption, provider delay, data-quality issue, source-report error, schema change, or failed task without unauthorized access;
  • exposure of data that the customer intentionally made public or directed Netice to disclose; or
  • issues involving data that Netice does not control or process.

18.2 Response Process

When Netice becomes aware of a suspected incident affecting the Services, Netice may take steps appropriate to the circumstances, including:

  • triage and assess available evidence;
  • contain or isolate affected components;
  • revoke sessions, rotate secrets, restrict access, pause tasks, or block traffic;
  • preserve relevant evidence;
  • investigate scope, root cause, and impact;
  • remediate or mitigate the issue;
  • restore or rebuild affected services;
  • coordinate with customers, providers, legal counsel, insurers, regulators, law enforcement, or other parties where appropriate; and
  • document lessons and improve controls where reasonably warranted.

18.3 Notification

Netice will provide notifications required by applicable law or an applicable written agreement. The timing, content, recipient, and method of notice depend on Netice’s legal role, available facts, risk, law-enforcement restrictions, provider coordination, and the need to avoid increasing harm. Netice does not promise a fixed notification period beyond what applicable law or contract requires.

Netice may provide updates as material information becomes reasonably available. Initial notices may be incomplete. Netice may withhold technical details that could enable misuse, reveal another customer’s information, compromise an investigation, violate law, or disclose protected security information.

18.4 Customer Cooperation

Customers must promptly provide accurate information, preserve relevant logs, rotate affected credentials, follow containment instructions, investigate customer-controlled systems, and notify their own users, regulators, counterparties, insurers, or other parties where the customer is legally responsible. Netice is not responsible for a customer’s failure to act on a security notice.

19. Privacy and Legal-Security Obligations

  • Netice applies technical and organizational measures intended to provide a level of security appropriate to the relevant risk, taking account of the nature and context of processing, available technology, implementation cost, and reasonably foreseeable threats.
  • Netice may act as a controller for account, website, billing, security, fraud-prevention, support, and business-contact data and as a processor or service provider for Customer Data, as further described in the Privacy Policy and any applicable DPA.
  • Netice does not sell Customer Data as a data broker and does not use Customer Data for unrelated third-party advertising.
  • Cross-border processing and data location may depend on the selected source, destination, cloud provider, identity provider, payment provider, support channel, and customer configuration. Netice does not guarantee that all data remains in a particular country or region unless expressly agreed in writing.
  • Customers are responsible for choosing lawful source and destination regions, providing notices, obtaining permissions, executing required agreements, responding to data-subject requests, and determining whether the Services are appropriate for their regulatory obligations.
  • Privacy rights, legal bases, categories of personal data, recipients, transfers, and retention are governed by the Privacy Policy and applicable DPA rather than this Security Policy.

Nothing in this Policy constitutes a representation that Netice is certified, approved, or compliant with every law, framework, standard, or industry requirement applicable to a particular customer. Customers with specific regulatory or contractual requirements must obtain Netice’s written agreement before relying on the Services for those requirements.

20. Customer Security Responsibilities

Without limiting the Terms, customers and their authorized users are responsible for the following:

  • Account security: use unique credentials, enable available MFA where appropriate, protect recovery channels, review active users, and promptly offboard former users.
  • Role governance: assign the minimum necessary role, review organization membership, restrict owners and editors, and avoid shared accounts.
  • Source security: protect App Store Connect, Google Play, cloud, warehouse, storage, and other provider accounts; use dedicated least-privileged access; and monitor provider-side activity.
  • Destination security: configure private access, IAM, encryption, region, logging, backups, lifecycle, cost controls, and downstream access.
  • Credential lifecycle: provide valid credentials, rotate them, revoke unused grants, respond to compromise, and understand that deleting a Netice record does not necessarily revoke provider access.
  • Data classification: ensure Customer Data is lawful, accurate enough for the intended purpose, non-malicious, and permitted under the Terms; do not submit Restricted Data without a signed agreement.
  • Configuration review: verify selected sources, report families, dates, currencies, destinations, table or object targets, schemas, and schedule settings before relying on output.
  • Output verification: reconcile material outputs against authoritative sources and professional accounting, tax, legal, or compliance requirements.
  • Business continuity: maintain destination backups, incident procedures, alternative access, and recovery plans appropriate to the customer’s business.
  • Endpoint security: secure browsers, devices, networks, password managers, email accounts, and local storage used to access Netice.
  • Support hygiene: provide only the minimum evidence required and never send raw credentials, private keys, tokens, session cookies, full card data, or unrelated customer data.
  • Incident reporting: notify Netice promptly through the Support Portal if compromise, unauthorized access, suspicious tasks, or credential exposure is suspected.
  • Legal compliance: comply with laws, provider terms, intellectual-property rights, confidentiality duties, sanctions, export controls, and third-party restrictions.

A customer’s failure to meet these responsibilities may prevent Netice from protecting the account or completing a task and may result in suspension, data loss, unauthorized access, inaccurate output, increased cost, or legal exposure.

21. Prohibited Security Activity and Protective Action

Except where Netice has provided prior written authorization that identifies the exact scope, systems, dates, methods, contacts, and conditions, customers and third parties must not:

  • access or attempt to access an account, workspace, task, connection, secret, report, destination, administrative surface, or data that they do not own or have express authority to access;
  • conduct automated, high-volume, disruptive, destructive, or intrusive testing or assessment of the Services;
  • attempt to bypass authentication, authorization, tenant isolation, role checks, subscriptions, quotas, rate limits, request limits, origin checks, CSRF controls, application-integrity controls, machine authentication, logging, cost controls, or other safeguards;
  • misuse credentials, sessions, authentication factors, account-recovery processes, trial access, billing processes, or multiple identities to obtain or retain unauthorized access or evade restrictions;
  • disrupt, degrade, overload, exhaust, or disproportionately consume the Services, provider resources, queues, tasks, connections, or other operational capacity;
  • transmit harmful code, malicious files, destructive data, or content intended to compromise, damage, or interfere with Netice or a third party;
  • derive, copy, obtain, or disclose non-public source code, security logic, models, datasets, or confidential information except to the limited extent such restriction is prohibited by applicable law;
  • deceive, impersonate, coerce, threaten, or physically target Netice personnel, contractors, customers, or providers;
  • intercept traffic, test third-party providers through Netice, use stolen credentials, or involve data or systems for which the tester lacks authorization;
  • modify, delete, corrupt, retain, remove, publish, redistribute, or unnecessarily access data encountered during any assessment or suspected vulnerability;
  • publicly disclose a suspected vulnerability, incident, customer information, or attack-enabling detail without Netice’s prior written consent; or
  • demand payment, threaten disclosure, withhold material remediation information, or condition a report on compensation.

Netice may investigate suspected violations and may preserve evidence, restrict access, notify affected customers or providers, report activity to authorities, and pursue contractual, civil, or criminal remedies. Protective measures may affect legitimate activity, and Netice is not obligated to disclose detection criteria or provide advance notice where doing so would undermine security.

22. Vulnerability Reporting Rules

22.1 Reporting Channel

To report a suspected security vulnerability, use the Netice Support Portal and place “SECURITY REPORT” at the beginning of the message. If the Support Portal is unavailable, email info@netice.fi with the subject “Security Report”.

22.2 Required Report Content

A useful report should include only the minimum information necessary to understand and reproduce the issue safely:

  • the reporter’s name and reliable contact details;
  • a concise description of the suspected vulnerability and potential impact;
  • the affected Netice-owned URL or feature, without including internal identifiers belonging to another customer;
  • safe, non-destructive reproduction steps using only the reporter’s own authorized account and synthetic data;
  • the date and approximate time observed;
  • relevant request or response metadata with credentials, cookies, tokens, personal data, customer data, and internal identifiers removed;
  • screenshots or proof that do not expose another person’s data or secret; and
  • whether the reporter has shared the issue with anyone else.

22.3 This Is a Reporting Channel, Not Authorization to Test

Submitting a report does not grant permission to access, assess, interfere with, or modify any Netice or third-party system. Netice does not provide a general safe harbor, bug-bounty authorization, waiver of rights, or exemption from applicable law through this Policy. Any active testing requires Netice’s prior written authorization.

22.4 Mandatory Reporter Conduct

  • Use only an account, data, source, destination, and infrastructure that you own or are expressly authorized to use.
  • Do not access another customer’s workspace, data, task, credentials, destination, or identifiers.
  • Stop immediately if you encounter personal data, Customer Data, credentials, secrets, payment data, or evidence of active compromise.
  • Do not download, retain, copy, alter, delete, or redistribute encountered data. Preserve only the minimum redacted evidence needed to report the issue.
  • Do not use automated or high-volume tools, harmful content, disruptive techniques, deceptive conduct, physical targeting, credential misuse, or third-party systems.
  • Do not establish continued access, move beyond the minimum authorized observation, increase privileges, or repeatedly reproduce the issue.
  • Keep the report and all related information confidential unless Netice gives prior written approval for disclosure.
  • Comply with applicable law, provider terms, and Netice instructions.

22.5 No Bounty or Compensation Commitment

Netice does not operate a public bug-bounty program and has no obligation to provide payment, credit, merchandise, employment, reimbursement, or other compensation. Any reward or public acknowledgement is entirely at Netice’s discretion and requires a separate written agreement made before any compensated work.

22.6 Report Handling

  • Netice may acknowledge, investigate, prioritize, reproduce, remediate, mitigate, reject, or close a report at its discretion, subject to applicable law and contract.
  • Netice does not guarantee a response, status update, remediation, publication, or resolution timeline.
  • Duplicate, incomplete, theoretical, non-actionable, out-of-scope, third-party, reporter-only, best-practice-only, informational version, header-observation, rate-limit, or low-impact reports may be closed without action where Netice determines they do not create material risk.
  • Netice may share a report with cloud providers, identity providers, affected customers, legal counsel, insurers, regulators, law enforcement, or other parties as reasonably necessary to investigate, remediate, protect rights, or comply with law.
  • By submitting a report, the reporter represents that the reporter has the right to submit the material and grants Netice a worldwide, perpetual, irrevocable, royalty-free, non-exclusive license to use, reproduce, modify, disclose, and otherwise process the report and evidence for security, legal, operational, and remediation purposes.
  • Netice may request deletion of retained evidence or confirmation that the reporter has not retained Customer Data or secrets.

22.7 Unauthorized Activity

Activity outside these rules may be treated as unauthorized regardless of whether the person later submits a report. Netice reserves all rights and remedies. Nothing in this Policy limits Netice’s ability to investigate, block, report, or bring claims arising from unlawful, harmful, negligent, coercive, or unauthorized activity.

23. Security Assurance, Questionnaires, and Audit Requests

  • Customers may submit reasonable security questions through the Support Portal. Netice may answer through standardized documentation, a questionnaire, a call, or confidential materials.
  • Netice may require a non-disclosure agreement before providing non-public security information.
  • Netice may decline or limit requests that are duplicative, disproportionate, speculative, technically unsafe, commercially unreasonable, or likely to expose confidential information or increase risk.
  • Unless required by law or a signed agreement, customers have no right to inspect source code, infrastructure, internal logs, vulnerability details, independent technical-assessment reports, provider contracts, other customers’ data, personnel records, or security evidence.
  • Any agreed audit must be documented in advance, limited in scope, non-disruptive, conducted by an independent qualified auditor, subject to confidentiality and security restrictions, and performed at the requesting customer’s expense unless otherwise agreed.
  • No audit, questionnaire, review, demonstration, or document creates a warranty that the Services are vulnerability-free or fit for a customer’s particular regulatory purpose.

23.1 Standards and Frameworks

Netice may use recognized security materials and risk-management practices as reference points when evaluating controls. Reference to a standard or framework does not mean Netice has been independently assessed, certified, or found conformant with that standard unless Netice expressly publishes a current, specific attestation.

24. Security Disclaimers and Limitation of Commitments

To the fullest extent permitted by applicable law and without limiting the Terms:

  • the Services and security measures are provided on an “as is” and “as available” basis;
  • Netice does not warrant that the Services are invulnerable, uninterrupted, error-free, free of malicious activity, or capable of preventing every unauthorized act;
  • Netice does not warrant that every vulnerability will be discovered, reported, prioritized, remediated, or remediated within a particular period;
  • Netice does not warrant the security, accuracy, completeness, availability, or conduct of a third-party source, destination, provider, integration, network, or customer-controlled system;
  • the existence of encryption, logging, monitoring, testing, backup, retry, redaction, or access-control measures does not create an absolute guarantee of confidentiality, integrity, availability, recoverability, or compliance;
  • security descriptions in marketing, documentation, questionnaires, or this Policy do not expand Netice’s liability, indemnity, warranty, or service obligations beyond an applicable signed agreement;
  • the limitations of liability, exclusions, indemnities, suspension rights, dispute provisions, and other protections in the Terms apply to security-related claims to the fullest extent permitted by law; and
  • nothing in this Policy creates rights for any third-party beneficiary.

Customers that require a specific control, certification, region, encryption model, retention period, incident-notification term, audit right, recovery objective, or service level must obtain that requirement in a signed written agreement before using the Services in reliance on it.

25. Policy Changes and Contact Information

25.1 Changes

Netice may update this Policy to reflect changes in the Services, providers, threats, legal requirements, security practices, or business operations. The current version will be published on the relevant Netice policy page with an updated date. Netice may make urgent security-related changes without prior notice where advance disclosure or delay could increase risk.

25.2 Contact

For security questions, suspected account compromise, or vulnerability reports, use the Netice Support Portal. If the portal is unavailable, contact info@netice.fi.

For information about personal-data processing and privacy rights, see the Privacy Policy. Use of the Services remains subject to the Terms of Service.

Netice Oy
Finland