Privacy Policy

Privacy Policy — User Access Management (UAM) Application by Silensec
Effective Date: 01st October 2026 | Last Updated: 17th September 2026
1. Introduction
This Privacy Policy describes how Silensec LTD (“we,” “us,” “our”) collects, uses, stores, and protects information in connection with the User Access Management (UAM) application (“the Application”), including its web platform and its companion Android mobile application (“the Mobile App”). The Application is deployed within client environments to enable customers to request, review, monitor, and manage system access for their users.
This policy applies to all data processed by the Application, whether accessed directly by client administrators through the web platform, through the Mobile App, or reviewed by Silensec personnel for support and maintenance purposes.

2. Scope and Deployment Model
The Application is installed within the customer’s own environment (“on-premises” or “client-hosted deployment”). As a result:
• Data processed by the Application generally remains within the customer’s infrastructure.
• Silensec acts as a data processor on behalf of the customer (the data controller), unless otherwise specified in a signed Data Processing Agreement (DPA).
• The customer is responsible for determining the lawful basis for processing access-review data within their organization.
• The Mobile App is a client to this same environment: it communicates only with hosts belonging to the customer’s tenant and does not introduce a separate data-processing location (see Section 5).

3. Information We Collect
The Application may collect and process the following categories of information:
3.1 User Account and Identity Data
• Usernames, employee IDs, and email addresses
• Job titles, department, and organizational role
• Manager/reporting line information (where used for approval workflows)
3.2 Access and Entitlement Data
• System, application, and resource access rights
• Role assignments and permission levels
• Access request, approval, and revocation history
• Timestamps of access grants, changes, and reviews
3.3 Audit and Activity Logs
• Login and authentication events related to access reviews
• Actions taken within the Application (e.g., approvals, rejections, comments)
• IP address and device information used to access the Application (if logged)
3.4 Technical Data
• System configuration and integration metadata (e.g., connected directories, identity providers)
• Error logs and diagnostic data used for support purposes
3.5 Data Collected Specifically by the Mobile App
The Mobile App collects a narrower, purpose-limited set of information, separate from the data categories above:
• The organisation code entered by the user
• The push notification token generated by Firebase Cloud Messaging
• The content of QR codes scanned at the user’s initiative, passed directly to the web application (no image is stored)
• Files the user chooses to upload (15 MB limit per file)
The Mobile App does not collect location, contacts, advertising identifiers, or application usage data. Geolocation requests made by web content loaded inside the app are denied by the native code.
We do not intentionally collect special categories of personal data (e.g., health, biometric, or financial data) unless such data is inherently part of a client’s access control structure and is provided by the client.

4. How We Use Information
Information processed by the Application is used solely to:
• Enable customers to review and certify user access to systems and applications
• Generate access review reports, dashboards, and audit trails
• Support compliance with regulatory or internal governance requirements (e.g., SOX, ISO 27001, SLA obligations)
• Provide technical support, troubleshooting, and maintenance of the Application
• Improve the security, performance, and reliability of the Application, including the Mobile App
We do not use client data for advertising, profiling unrelated to access management, or resale to third parties.

5. Mobile Application: Permissions, Storage, and Data Handling
This section sets out details specific to the Mobile App, which operates as a thin, security-hardened client to the web platform described elsewhere in this policy.

5.1 Permissions Requested
• Internet access and network state (required for the app to function)
• Camera — requested at the point of use, solely for QR code scanning. The app remains usable if this permission is denied; only QR scanning becomes unavailable. The camera is active only while the scanning screen is open, and no image is stored or transmitted — only the decoded string is returned.
• Notifications — requested at the point of use, to display push messages. The app remains usable if this permission is denied; only push notifications become unavailable.
No permissions are requested for location, contacts, microphone, telephone, SMS, calendar, or access to the device’s shared files.

5.2 Third-Party Components and Integrations
• Firebase Cloud Messaging (Google), used for push notifications. Firebase is initialized only after the user indicates their organisation, and each tenant uses a separate Firebase project, so tokens belonging to different customers do not share notification infrastructure.
• AndroidX, Material, Volley, and Gson (Google) — standard interface and networking libraries.
• An open-source QR decoding library, which operates entirely on-device (locally).
No analytics are integrated: neither Firebase Analytics nor any behavioural analytics platform is present, and no usage events are collected. No crash reporting is integrated: neither Crashlytics nor an equivalent service is present, and the app transmits no crash reports or diagnostics.

5.3 Data Stored on the Device
All app data is stored within the app’s private sandbox on the device, inaccessible to other applications:
• In clear text: the organisation code and the counters used for anti-brute-force protection (not personal data).
• Encrypted with AES-256-GCM, using a non-exportable key held in the Android Keystore: the push token and any values the web application persists. If the key is ever invalidated, the affected value is treated as absent rather than returned in clear text, and re-authentication is required.
• The documents the user chooses to download.
• The WebView cache, which is cleared when the app closes.
Automatic backup is disabled: app data is excluded from Google’s cloud backup and from transfers to a new device.

5.4 Data Transmitted by the Mobile App
Application traffic from the Mobile App goes exclusively to the hosts of the customer’s own environment, over HTTPS. The permitted addresses are a closed list compiled into the app; a link originating from a tenant other than the one configured on the device is not opened. The only data disclosed to Google (via Firebase) is the device’s push registration token, as required to deliver notifications. No data from the Mobile App is sent to Silensec or to any other third party the app contains no telemetry or data-collection endpoint of that kind.
For accuracy: push notifications necessarily transit Google’s Firebase infrastructure, as with any Android app that uses notifications, and the transiting message includes the notification title and body. Substantive content itself remains on the platform and is retrieved by the app only after authenticated access.

5.5 Encryption and Additional Technical Safeguards
• Encryption in transit: HTTPS is mandatory for all hosts; unencrypted traffic is disabled; mixed content is prohibited; a TLS certificate error cancels page load with no option to proceed. The app trusts only system certificate authorities, not any certificate installed on the device.
• Encryption at rest: sensitive values are encrypted with AES-256-GCM via a non-exportable Android Keystore key, in addition to the device’s filesystem encryption.
• The communication channel between web content and native app features is restricted to the customer’s own addresses and to the main frame, and is not enabled at all in production if it cannot be enabled securely.
• Remote content debugging is enabled only in development builds, never in production.
• Diagnostic logging is stripped from production builds, so tokens and notification content cannot reach device logs.

5.6 Support Access via the Mobile App
The Mobile App contains no remote access mechanism of any kind — no screen sharing, no remote control, and no remote log collection. There is no channel through which Silensec support personnel could reach a device or the data held on it through the Mobile App itself.
Controls around support-access logging and time-limited support access are implemented and audited at the web platform level, as described elsewhere in this policy; they do not apply to the Mobile App, which has no support-access channel to log or time-limit.

6. Data Storage and Location
• Data is stored within the customer’s designated environment (on-premises servers, private cloud, or customer-managed cloud tenancy), as agreed in the deployment/implementation contract.
• Where Silensec personnel require remote access to the web platform for support purposes, that access is logged, time-limited, and subject to the customer’s security controls (see Section 5.6 regarding the Mobile App specifically).
• Silensec does not transfer client data outside the customer’s environment unless explicitly authorized in writing (e.g., for hosted/managed service offerings).
• On-device storage used by the Mobile App is described in Section 5.3 and remains within the app’s private sandbox on the user’s device.

7. Data Sharing and Disclosure
We do not sell or rent personal data. Data may be shared only in the following circumstances:
• With the customer’s own authorized personnel (administrators, approvers, auditors) as configured within the Application
• With Silensec support or engineering staff, strictly for troubleshooting, under confidentiality obligations
• With subprocessors or subcontractors engaged by Silensec, where applicable, and only under equivalent data protection terms — for the Mobile App, this is limited to Google (Firebase), which receives only the device’s push registration token (see Section 5.4)
• Where required by law, regulation, or valid legal process

8. Data Retention
8.1 Platform-Level Retention
• Access review records and audit logs are retained according to the retention schedule agreed with each customer, typically to satisfy compliance and audit requirements.
• Customers control retention settings within the Application where configurable.
• Upon contract termination, data is deleted, returned, or retained solely per the terms of the applicable service agreement.

8.2 Mobile App Retention and Deletion
• On logout: the app deregisters the device from notifications on the platform (the deregistration call is made while the session is still valid), clears the local reference to the push token, wipes the web application’s session data, and returns the user to the sign-in screen; the server-side session is closed. Only the organisation code remains on the device, so it need not be re-entered on the next launch.
• On access revocation: the effect is immediate, since authorization is verified by the platform on every request. The session on the device stops working and the user is returned to authentication. Because access relies on a session cookie rather than locally held credentials, nothing reusable for regaining entry remains on the phone.
• On uninstall: Android removes the app’s entire data area — preferences, the encrypted store, the cache, and downloaded documents. As backup is disabled, no cloud copy exists from which data could resurface on another device, and the encryption key, being bound to the device and non-exportable, is not recoverable.
• Downloaded documents (for example, PDF reports the user has explicitly downloaded) remain in the app’s private area after logout and are removed on uninstall or by manual deletion. This is expected behaviour for files the user requested; a customer requiring that nothing persist after logout can agree this as a configuration change with Silensec.
• Account and data deletion is exercised on the platform, which holds the authoritative data; the Mobile App retains no authoritative copies and aligns automatically — once an account is deleted, access is no longer possible and nothing meaningful remains on the device. Uninstalling the app is sufficient to remove all local traces.

9. Data Security
We implement administrative, technical, and physical safeguards designed to protect data processed by the Application, including:
• Role-based access controls and authentication mechanisms
• Encryption of data in transit and, where applicable, at rest (see Section 5.5 for Mobile App-specific detail)
• Audit logging of administrative and support access at the platform level
• Regular security patching and vulnerability management
• Adherence to applicable security frameworks (e.g., ISO/IEC 27001)
Despite these measures, no system can guarantee absolute security. Customers are responsible for securing their own environment in which the Application is deployed.

10. Data Subject Rights
Depending on applicable law (e.g., GDPR, POPIA, or other regional data protection regulations), individuals whose data is processed through the Application may have rights including:
• Right to access their personal data
• Right to correct inaccurate data
• Right to request deletion, where applicable
• Right to object to or restrict certain processing
•
As Silensec typically acts as a data processor, such requests should generally be directed to the customer (data controller) operating the Application. Silensec will support customers in fulfilling these requests as required under the applicable DPA.

11. Subprocessors
Silensec may engage third-party subprocessors (e.g., cloud infrastructure providers, support tools) to assist in delivering and supporting the Application. For the Mobile App specifically, the only such subprocessor is Google (Firebase Cloud Messaging), which receives solely the device’s push registration token as described in Section 5.4. A current list of subprocessors is available upon request or as referenced in the applicable DPA.

12. Cookies and Tracking
If the Application includes a web-based interface, it may use session cookies or similar technologies strictly necessary for authentication and functionality. No third-party advertising or tracking cookies are used. The Mobile App does not use cookies; equivalent session state is held in the app’s private, encrypted on-device storage as described in Section 5.3.

13. Changes to This Policy
We may update this Privacy Policy periodically to reflect changes in our practices, technology, legal requirements, or other factors. We will notify customers of material changes as required under the applicable service agreement.

14. Contact Us
For questions about this Privacy Policy or how data is processed within the Application, please contact:
Silensec LTD
G & N Court, 41 Pafou Street, Cyprus.
info@silensec.com

Scroll to Top