OneNymPublic exposure
Public files and data can be retrieved by anyone.
Protection approach
Define intended audiences and review storage and distribution settings.
PERSONAL DATA / EXPOSURE PATHS
Personal data.
Where can it leak?
Personal data needs more than one boundary.
Public access, authentication, permissions, encryption.
When one layer fails, can the next contain it?
LAYERS OF DEFENSE
Is there another boundary beyond the first?
Public data can be retrieved directly. Private intent does not help without access controls. Stolen permissions may be treated as legitimate access. Connect protections from entry points to the moment data is used.
From entry to data
- 01
Public exposure
Define who should see the information.
- 02
Access restrictions
Knowing the location does not grant read access.
- 03
System defenses
Prevent intrusion through weaknesses and configuration errors.
- 04
Authentication
A stolen password alone should not grant entry.
- 05
Additional authentication
Protect authentication methods, devices, and sessions.
- 06
Data permissions
A login should not expose every record.
- 07
Data and key separation
Stolen stored data alone should not be decryptable.
PERSONAL DATANames, addresses, contact details, and history
Only necessary data, only to authorized actors.
This is a conceptual diagram of defense roles, not a mandatory attack sequence. MFA resilience varies by method and endpoint state; it is not universally bypassed.
25 EXPOSURE POINTS
Entry, permissions, integrations, copies.
Follow the whole data flow.
Misuse, mistakes, and incomplete deletion also cause exposure. These 25 representative points are grouped by where information becomes accessible. Multiple points can combine in one incident.
01 / ENTRY AND AUTHENTICATION
Are the entry points protected?
Access restrictions
Data meant to be private can be read by anyone who knows the URL.
Protection approach
Do not rely on hidden URLs. Check authentication and permissions on every retrieval.
System defenses
Software vulnerabilities or configuration errors allow intrusion.
Protection approach
Manage patches and configurations, and restrict movement after entry.
Authentication
Stolen passwords let attackers sign in as the user.
Protection approach
Combine MFA with detection of suspicious logins.
Additional authentication
Compromised devices or manipulated approval requests defeat additional authentication.
Protection approach
Use phishing-resistant authentication and protect endpoints.
Authenticated sessions
Stolen sessions permit actions without knowing the password.
Protection approach
Protect sessions, reauthenticate sensitive actions, and provide revocation.
Account recovery and identity checks
Strong login controls are bypassed through reset flows or support desks.
Protection approach
Treat account recovery as part of the authentication boundary.
02 / INTERNAL PERMISSIONS AND KEYS
Contain access even after entry.
Data permissions
One account can read more customer data than its workflow needs.
Protection approach
Limit fields, records, purposes, and time windows on every request.
Data and key separation
Ciphertext and decryption permissions are stolen together.
Protection approach
Separate storage access from key use and restrict decryption paths.
Insiders and legitimate accounts
Authorized employees or contractors export data improperly.
Protection approach
Apply least privilege, audit operations, and approve sensitive actions.
Exports and bulk retrieval
Broad read permissions allow all records to be retrieved through search or CSV export.
Protection approach
Separate ordinary viewing from bulk export and monitor volume.
Access after employment or contract ends
Unused accounts and integration grants remain active.
Protection approach
Expire and review permissions for both people and services.
Customer and tenant boundaries
A legitimate user can retrieve another person's or company's data.
Protection approach
Check ownership and tenancy server-side, not only in the interface.
03 / INTEGRATIONS AND SUPPLY CHAIN
Some paths bypass your own perimeter.
Vendors and external services
Data is stolen from a recipient without breaching your systems.
Protection approach
Share less data and review vendor permissions, retention, and deletion.
API keys and integration tokens
Service credentials retrieve data without using human passwords or MFA.
Protection approach
Scope each integration and manage secret storage, rotation, and revocation.
Development and deployment
Compromised code or deployment systems introduce data-stealing changes.
Protection approach
Review changes and control deployment access, dependencies, and secrets.
External browser scripts
Tags or external components capture entered information.
Protection approach
Restrict loaded code and destinations and track changes.
AI and analytics inputs
Data sent to external tools is retained or shared unexpectedly.
Protection approach
Define permitted inputs and retention terms; remove unnecessary personal data.
04 / COPIES AND DATA LIFECYCLE
Data remains outside the protected store.
Logs, backups, and test environments
Copies leak from another location even if production is protected.
Protection approach
Track copy locations and permissions. Use dummy data for testing.
Endpoints and downloaded files
Retrieved data remains on computers and shared folders.
Protection approach
Reduce exports and protect endpoints, files, and retention periods.
Misdelivery and incorrect sharing
Wrong recipients or sharing settings expose data without an attack.
Protection approach
Check recipients, scope, and expiry and provide revocation options.
Temporary files, caches, and queues
Intermediate data persists and becomes accessible through another path.
Protection approach
Apply access controls and deletion deadlines to temporary data.
Incomplete deletion and restoration
Deleted information remains in replicas or returns from backups.
Protection approach
Track deletion targets and reapply current deletion records after restoration.
Paper, printouts, and removable media
Lost documents, stolen USB drives, or improper disposal expose data.
Protection approach
Control transport, storage, and disposal and minimize retained information.
Re-identification by combining data
Histories and attributes identify a person even after names are removed.
Protection approach
Evaluate combined identification risks, not only direct identifiers.
These are representative paths. Actual assessment scope depends on data locations, workflows, systems, and partners.
THE ONENYM APPROACH
Prevent intrusion. If it happens,
contain access to personal data.
Assess your current boundaries.
Within an authorized scope, test paths to personal data access, viewing, and export. Prioritize dummy and canary data and report affected information and remediation priorities.
Discuss assessment scope →Retain less data. Grant less access.
Proxy IDs, scoped tokens, authorization, and a vault reduce personal data exposure while keeping necessary workflows running.
Explore the privacy platform →