Version 1.0 · August 2026
Technical and Organisational Measures (TOMs)
Scope of this document
Operator: Herr Godfrey Mwasanje c/o Block Services Stuttgarter Straße 106 70736 Fellbach Deutschland Email: contact@revealmyrisk.com
This document describes the technical and organisational security measures implemented by RevealMyRisk (the "Processor") in respect of personal data processed on behalf of a customer (the "Controller") under the RevealMyRisk Data Processing Agreement (DPA). It is aligned with Article 32 of Regulation (EU) 2016/679 (GDPR) and forms an expanded presentation of the security annex to the DPA. In case of conflict, the DPA prevails.
1. Approach to security
The Processor implements measures appropriate to the nature, scope, context and purposes of the processing carried out for the Controller, and to the risks of varying likelihood and severity for the rights and freedoms of natural persons. Measures are reviewed periodically and may be updated to reflect technical and organisational developments, provided the level of security is not diminished.
2. Pseudonymisation and encryption (Art. 32(1)(a))
Encryption in transit. All connections to the platform, its interfaces and between infrastructure components are encrypted using TLS 1.2 or higher, with TLS 1.3 preferred.
Encryption at rest. Production data and backups are encrypted at rest using AES-256 by the managed European hosting and database platform used by the Processor.
Password storage. Account passwords are stored exclusively as salted cryptographic hashes by the managed authentication service. Plaintext passwords are never written to disk or retained.
Device binding. Sessions are bound to an approved device by way of a non-reversible device fingerprint hash; the underlying raw device characteristics are not stored.
Credential isolation. Connection credentials for upstream intelligence sources are stored server-side only and are never transmitted to the browser.
3. Confidentiality, integrity, availability and resilience (Art. 32(1)(b))
Confidentiality. Access to personal data is restricted to authorised personnel on a need-to-know basis through role-based access control. Database access is additionally constrained by row-level security policies enforced at the database engine. Multi-factor authentication is enforced on administrative and infrastructure access.
Integrity. Every privileged action is written to an append-only audit trail. Production environments are logically isolated from development and preview environments, and changes reach production only through a controlled deployment pipeline.
Availability. Production workloads run on managed European infrastructure with redundant power, connectivity and automated failover provided by the hosting platform.
Resilience. Production data is backed up automatically to encrypted storage within the EU/EEA, with point-in-time restore capability offered by the managed database platform.
4. Ability to restore availability and access (Art. 32(1)(c))
Encrypted backups support the restoration of availability and access to personal data in the event of a physical or technical incident. Restoration is carried out on a best-effort basis. The Processor does not currently commit to specific Recovery Time Objective (RTO) or Recovery Point Objective (RPO) targets, given its present operational scale and the absence of a 24/7 service level commitment.
5. Regular testing, assessing and evaluating effectiveness (Art. 32(1)(d))
The Processor monitors security advisories and vulnerability disclosures relevant to the components in use. Automated security and dependency scanning is run against the application and its database policies, security-relevant patches are applied promptly upon assessment, access rights are reviewed periodically, and these measures are themselves reviewed periodically.
6.1 Access control and authentication
Role-based access control restricting access to personal data to authorised personnel on a need-to-know basis.
Accounts are provisioned exclusively by the operator or an authorised administrator; there is no public self-registration for production access.
Accounts carry a defined validity period and are automatically set to expired once that period lapses; trial accounts additionally lose all module assignments on expiry.
Sessions are bound to one approved device; access from an unapproved device is refused until explicitly approved.
Multi-factor authentication enforced on administrative and infrastructure access (hosting console, source-code repository, deployment tooling, email).
Periodic review of access rights and removal of access on personnel or role changes.
6.1.1 Device recognition and device binding
Signals read in the browser at sign-in: user agent string, browser language settings, hardware concurrency and reported device memory, screen resolution, colour depth and pixel ratio, time zone and UTC offset, and the rendering signature of a small canvas drawing.
Pseudonymisation: these signals are concatenated and hashed with SHA-256 into a single non-reversible token. Only the hash is transmitted and stored; the individual signals are neither sent to the server nor persisted, and cannot be reconstructed from the hash.
Storage: the fingerprint is held in a dedicated device register linked to the user profile, together with an optional label, approval status, registration date and last login. Rows are protected by row-level security and are readable only by the owning user and administrators.
Enforcement: for device-locked accounts every login compares the submitted fingerprint against registered devices. Unknown fingerprints are rejected; known but unapproved devices remain blocked pending administrator approval. Approvals, revocations, resets and deletions are performed server-side and recorded in the audit log.
No cookies, advertising identifiers, IP-based recognition or client-installed agents are used for device identification, and fingerprints are never used for marketing, profiling or cross-site tracking. Fingerprints are erased when the device entry or the account is deleted.
6.2 Network and infrastructure security
TLS enforced for all external and inter-component connections.
The production database is not exposed with unrestricted privileges; all application access passes through row-level security policies evaluated against the authenticated identity.
Privileged database credentials are held server-side only and are never present in browser-delivered code.
Edge protection including DDoS mitigation and TLS termination is provided by the hosting platform's global edge network.
Logical isolation between production and preview environments.
Hosting on managed infrastructure with data residency in the EU/EEA.
6.3 Application security and change management
Application source code is managed in a version-controlled repository with access restricted to authorised personnel. Changes are deployed to production through an automated build and deployment pipeline, with a separate preview environment used for pre-production validation. Dependency and supply-chain advisories are monitored and reviewed.
6.4 Logging and monitoring
A centralised audit trail records authentication events, administrative actions and query metadata (timestamp, account identifier, module used, action performed and IP address). Logs are retained for up to twelve (12) months and then deleted or anonymised.
Query results are not stored beyond the session, and reports are generated locally in the user's browser.
No third-party advertising, marketing or cross-site tracking technology is embedded in the platform, and no analytics cookies are set.
6.5 Vulnerability and patch management
The Processor maintains awareness of security advisories and CVE disclosures relevant to its technology stack. Security-relevant patches are reviewed and applied as part of regular operational maintenance, with prioritisation determined by assessed severity and exposure.
6.6 Backup and recovery
Production data is backed up automatically to encrypted storage within the EU/EEA using AES-256 encryption at rest. Restoration is performed on a best-effort basis as described in Section 4.
6.7 Physical security
Physical security of production infrastructure is inherited from the hosting providers' EU/EEA data centres, which operate access control, environmental controls, fire suppression, redundant power and connectivity, and end-of-life secure media disposal procedures. The Processor does not operate its own physical premises housing production data.
7. Personnel and organisational measures
RevealMyRisk is operated by Herr Godfrey Mwasanje as a single-operator business. The operator is the sole person with access to production systems and to personal data processed on behalf of the Controller, and is bound by statutory and contractual confidentiality obligations. No employees, contractors or interns currently have such access.
Confidentiality commitments bind any personnel who may in future be granted access to personal data. Engagement of any sub-processor is conditioned upon contractual data-protection obligations equivalent to those in the DPA.
8. Sub-processor management
Sub-processors are engaged only under contractual data-protection obligations equivalent to those in the DPA. The current sub-processors comprise the managed hosting, database and authentication platform, the transactional email provider, and the contracted breach-intelligence data provider. Changes are notified to the Controller at least thirty (30) days in advance, giving the Controller the opportunity to object on reasonable data-protection grounds.
9. Incident response and breach notification
Detection. Incidents are detected via centralised audit logging, monitoring and review of anomalous activity.
Reporting channel. Security researchers and customers may report suspected vulnerabilities or incidents to contact@revealmyrisk.com. Reports made in good faith are handled under a coordinated disclosure approach.
Notification to the Controller. The Processor notifies the Controller of any personal data breach affecting the Controller's personal data without undue delay and in any event within twenty-four (24) hours of becoming aware of it. A substantive update including the information required under Article 33(3) GDPR is provided within forty-eight (48) hours of the initial notification.
Cooperation. The Processor assists the Controller in meeting its own notification obligations to supervisory authorities (Art. 33) and to affected data subjects (Art. 34), taking into account the nature of processing and the information available to the Processor.
10. Periodic review
These measures are reviewed periodically and may be updated to reflect technical and organisational developments, provided the level of security is not diminished. Material changes affecting the Controller will be communicated in accordance with the DPA.