Institutional documents

Technical and Organisational Measures

This page summarises the technical and organisational measures used to protect personal data processed through Acadex.

The measures described here reflect the current state of the system.

They are not a list of planned controls presented as if they already existed.

Where a measure is still being formalised or an exact operational value has not yet been fixed, we say so explicitly.

For institutional customers, these measures can also form part of the documentation accompanying a Data Processing Agreement under Article 28 GDPR.

1. Purpose and scope

Acadex processes account information, research conversations, uploaded documents, saved memories, watchlists, bibliographic information, and technical operational data.

The measures described here are intended to protect this information against risks including:

• unauthorised access,
• unauthorised disclosure,
• accidental or unlawful alteration,
• accidental loss,
• inappropriate deletion,
• misuse of credentials,
• technical failure,
• and unauthorised processing.

The appropriate measure depends on the type of data and the function for which it is processed.

Not every category of information is protected in exactly the same technical way.

2. Infrastructure location

Acadex’s central application infrastructure is operated in Germany.

The primary PostgreSQL database is also operated in Germany.

Backups managed directly by Acadex are stored in Germany.

Our current infrastructure provider is:

STRATO GmbH

External model providers and other external services are treated separately because their processing locations depend on the processing path and account configuration.

3. Administrative access

Access to production infrastructure is limited to authorised administrative personnel.

At the current stage of Acadex, production administration is restricted to the technical lead.

If additional administrators are introduced, they are intended to receive individual administrative accounts rather than shared credentials.

Administrative access is granted according to operational need.

Access should be removed when it is no longer required.

4. Multi-factor authentication

Administrative access to relevant hosting and source-code infrastructure is protected with multi-factor authentication.

This currently includes administrative access to systems such as:

• the STRATO / Plesk hosting environment,
• source-code infrastructure on GitHub.

Multi-factor authentication for individual Acadex end-user accounts is not yet generally available.

We distinguish between those two statements rather than describing Acadex as universally protected by MFA.

5. Production SSH access

Production SSH access uses cryptographic keys.

Password-based SSH access is disabled for production administration.

Private access keys are handled separately from ordinary application credentials.

6. Authentication and passwords

Acadex does not store user passwords in plaintext.

Passwords are stored as cryptographic hashes using Argon2id.

Authentication and session mechanisms are designed so that access to an Acadex account requires the corresponding credentials or valid authenticated session.

Further account-security controls may be added as Acadex develops.

7. Encryption in transit

Communication between user devices and Acadex is protected using TLS.

TLS is also used where supported and appropriate for communication with external services.

The purpose is to protect information against unauthorised interception or modification while it is transmitted over networks.

8. Field-level encryption

Selected sensitive content stored by Acadex is additionally protected using field-level AES-256-GCM encryption.

This includes content such as:

• conversations,
• saved memories,
• uploaded documents,
• chat titles,
• stored request content.

The relevant encryption key is kept separately from the application database.

This reduces the risk that direct access to the database alone would expose the protected content in plaintext.

9. Searchable memory is an explicit exception.

Some saved context needs to remain searchable so Acadex can retrieve information relevant to a later request.

The text required for semantic memory search therefore cannot be protected with the same field-level encryption while it remains actively searchable.

We document this as an explicit exception.

We do not describe all stored memory content as identically encrypted when that would not be technically accurate.

Embeddings used for semantic retrieval are generated locally by Acadex.

No separate external embedding provider receives the memory text for this purpose.

10. Separation of encryption material

Encryption material used to protect sensitive database fields is kept separately from the primary application database.

A compromise of the database alone should therefore not automatically provide the key required to decrypt protected fields.

Access to encryption material is limited to authorised technical administration.

11. Secret management

API credentials, database credentials, encryption material, and comparable secrets are not stored in the application source code.

Secrets are maintained in a dedicated encrypted password-management system.

Production secrets are supplied to the application as runtime environment variables.

Access is currently restricted to the technical lead.

Secrets are rotated periodically, currently approximately every three months, and additionally where an incident or suspected credential exposure makes rotation appropriate.

12. Environment separation

Production, development, and testing environments are separated.

Production data is not routinely copied into development or test environments.

Development and testing should use dedicated data wherever possible.

Where production-related information is exceptionally required to investigate an issue, the amount of information should be limited to what is necessary.

13. Source-code management

Acadex source code is maintained in a version-controlled Git repository.

Development currently follows a monorepository structure.

Changes are generally developed on feature branches before being incorporated into the main production codebase.

Pull requests and review processes are used as part of change control.

The current team size means that the exact reviewer arrangement can depend on the nature of the change.

14. Testing

Automated unit tests are used as part of the development process.

Selected functionality is additionally checked through user-acceptance or manual testing.

Testing is intended to identify functional and security-relevant regressions before production deployment.

Acadex does not claim that automated tests can demonstrate the absence of vulnerabilities.

15. Deployment

Acadex is deployed using containerised application components.

Production deployments are currently performed by the technical lead.

Changes move into production through the development and deployment process rather than through direct routine modification of production application files.

Container and application dependencies are updated based on operational need and identified updates.

Operating-system-level maintenance is also handled through the hosting environment.

16. External model providers

Acadex can work with different external language-model providers.

A provider being technically integrated does not mean it may process data from every account.

For institutional configurations, Acadex can restrict which processing profiles are permitted.

A processing profile can define characteristics such as:

• provider,
• API endpoint,
• processing region,
• permitted models,
• retention controls,
• permitted provider features.

These restrictions can be enforced at the account level.

An individual user within a restricted institutional account cannot simply select a provider that has not been approved.

17. Supported is not the same as approved.

We distinguish between:

supported provider
A provider that Acadex can technically integrate with.

approved provider or processing profile
A provider or route permitted for a particular customer or institutional account.

actually used provider
A provider that receives information for a specific request.

This distinction is relevant both for technical controls and for subprocessor documentation.

18. Regional processing profiles

Where an institutional customer requires research content to be processed within a defined geographic region, Acadex can restrict the account to processing profiles approved for that requirement.

A regional profile is not considered available merely because a provider advertises regional processing.

Before such a profile is approved, the relevant implementation should be checked for matters including:

• endpoint configuration,
• supported models,
• processing location,
• retention behaviour,
• training controls,
• additional provider features,
• contractual processing arrangements.

Planned profiles are not presented as operational controls before they have been implemented and verified.

19. Local embeddings

Embeddings used for internal Acadex retrieval and semantic memory functions are generated locally.

Acadex does not currently use a separate external embedding API for these functions.

This reduces the number of external processors that would otherwise need access to the underlying text.

20. Internal search and vector infrastructure

Acadex uses internal search and vector components to support retrieval.

These systems contain derived data used to make information searchable.

They are distinguished from the primary PostgreSQL database because derived indexes can generally be reconstructed from their authoritative source data.

The existence of a reconstructable search index does not change the protection requirements for the underlying primary data.

21. Data minimisation

Acadex is designed to send external services only the information required for the function being performed.

A model provider used for one request does not automatically receive:

• an entire Acadex account,
• every previous conversation,
• every uploaded document,
• the complete memory store,
• all watchlists,
• or Acadex Product Metrics.

The required context depends on the task.

Data minimisation is therefore implemented as part of the processing architecture rather than only stated as a policy principle.

22. Product Metrics

Acadex processes a limited set of first-party operational, product, and business metrics.

These can include events or states such as:

• registration,
• activation,
• plan status,
• subscription start,
• cancellation,
• credit usage,
• active paid accounts,
• aggregated commercial metrics.

Product Metrics are designed to answer questions about whether Acadex is being used and whether the service operates sustainably.

They are not intended to reconstruct individual research behaviour.

23. No research-content analytics

Acadex does not use the following information for its own Product Analytics:

• conversation content,
• prompts,
• generated answers,
• uploaded document content,
• saved memories,
• research interests,
• research topics,
• bibliographic search queries.

Acadex does not currently use external behavioural analytics platforms, advertising pixels, or session-recording systems for Product Analytics.

We measure events, not behaviour.

24. Server-side website statistics

Acadex can generate limited website usage statistics on its own infrastructure.

These statistics can include page views of selected public pages.

For these statistics, Acadex does not create a persistent analytics visitor identifier.

We do not use browser fingerprinting.

Full IP addresses are not retained as long-term analytics identifiers.

URL query strings, search terms, and complete referring URLs are not retained for this purpose.

The system is intended to provide basic aggregate information without creating a detailed behavioural profile.

25. Operational logging

Operational logs are maintained where needed for:

• troubleshooting,
• service operation,
• rate limiting,
• abuse prevention,
• and security investigation.

Conversation content is not written to application logs.

Logs can contain technical identifiers such as user IDs where necessary for diagnosis.

IP addresses can be processed where required for controls such as rate limiting or security analysis.

26. Log retention

Local operational logs are currently retained for seven days.

Older logs can then be compressed, encrypted, and transferred to a separate archive server.

Archived logs are retained for no longer than three months.

Access to operational and archived logs is restricted to authorised administration.

Logs are not used to build profiles of individual research activity.

27. Data deletion

Users can delete individual data such as:

• conversations,
• memories,
• uploaded documents.

Users can also delete their entire Acadex account.

The application uses database relationships and cascading deletion mechanisms where appropriate to remove data associated with the account.

28. Schema-level deletion checks

Acadex additionally uses automated schema checks intended to identify database structures containing user-linked information that are not covered by the expected deletion process.

This is intended to reduce the risk that a newly introduced table silently falls outside account deletion logic.

No automated check can replace appropriate development review, but deletion behaviour is treated as a technical system property rather than only an interface feature.

29. Product Metrics after account deletion

Account-linked Product Metrics are generally deleted together with the account unless another legal retention obligation applies.

Metrics that have already been genuinely anonymised or aggregated can remain where they can no longer be associated with an identifiable account.

30. Backups and deletion

Deleting information from active systems does not necessarily remove every copy from an existing backup immediately.

Deleted information can remain in backup sets until those backups reach the end of their retention period.

Backups are not intended to be used to restore individual deleted user content into ordinary active use.

Where a full restore becomes necessary, deletion requirements must be considered as part of the recovery process.

31. Primary and reconstructable data

Acadex distinguishes between information that must be backed up directly and information that can be reconstructed.

The primary PostgreSQL database contains authoritative application data that cannot simply be recreated from public sources.

Other information can be derived or reconstructed, including parts of:

• search indexes,
• vector indexes,
• cached scholarly metadata,
• bibliographic datasets obtained again from external providers.

This distinction allows backup resources to focus on the data whose loss would otherwise be irreversible.

32. PostgreSQL backups

The primary PostgreSQL database requires dedicated backups separate from the reconstructable datasets around it.

A separate PostgreSQL backup process is part of the production protection model.

The final operational values for:

backup frequency: [to be finalised]

retention period: [to be finalised]

will be documented once fixed for production operation.

We do not publish invented backup intervals simply to make this document appear complete.

33. Full infrastructure backups

Acadex also maintains larger infrastructure-level backups.

Because the complete data environment currently exceeds several terabytes, these backups serve a different purpose from the more targeted protection of the primary PostgreSQL database.

Full backup sets are currently created approximately every three to four months.

They are not a substitute for appropriately frequent backups of primary transactional data.

34. Backup storage

Backups managed by Acadex are stored in Germany.

Backup copies are protected against ordinary public access.

Where archived data is transferred to separate backup infrastructure, appropriate access restrictions and encryption measures are used according to the type of backup.

35. Backup deletion

Backup deletion is carried out through the mechanisms available for the underlying storage environment.

We do not make claims such as guaranteed physical overwriting of individual SSD sectors where the storage abstraction does not allow us to verify that behaviour.

Instead, backup data is removed through the applicable storage and retention processes.

Cryptographic protection and retention limits form part of that model.

36. Restore testing

A backup is only useful if it can be restored.

Because the complete Acadex environment is large, we do not currently perform routine full multi-terabyte restoration tests of the complete infrastructure.

A dedicated restore-testing process for the primary PostgreSQL data is to be formalised separately.

The intended regular restore-test interval is currently:

[to be finalised]

Until that process is operationally established, we do not claim regular full restore testing.

37. Availability

Acadex currently runs as a single application instance.

The production deployment is not yet a redundant high-availability multi-instance architecture.

Acadex therefore does not currently claim automatic failover or uninterrupted availability.

A multi-instance architecture can be introduced later, but it is not part of the current measures described in this document.

38. Service-level commitments

Acadex does not currently offer a general uptime SLA.

Institutional service-level arrangements can be discussed separately where appropriate.

A contractual availability guarantee should only be made where the infrastructure and monitoring are capable of supporting that commitment.

39. Monitoring

Production systems are currently monitored administratively.

The current monitoring environment is not yet the fully automated monitoring and alerting system intended for later institutional scaling.

Additional monitoring infrastructure, including more structured observability, is planned.

Acadex does not currently describe its production environment as being subject to continuous automated 24/7 monitoring.

40. Incident response

Suspected security incidents are handled through a defined response sequence.

The operational model is:

identify → contain → investigate → assess → document → communicate → improve

Depending on the incident, this can include:

• disabling or rotating credentials,
• restricting affected access,
• preserving relevant logs,
• investigating affected systems,
• identifying potentially affected data and individuals,
• assessing notification obligations,
• informing affected controllers or customers,
• documenting decisions,
• implementing corrective measures.

41. Technical and communication responsibilities

Technical incident handling is currently coordinated by the technical lead.

Customer and external communication can be handled separately so that technical containment and communication do not unnecessarily interfere with each other.

Where Acadex acts as a processor, the relevant controller is informed in accordance with the applicable Data Processing Agreement and legal requirements.

Where Acadex acts as controller, applicable statutory notification obligations are assessed directly.

42. Security updates

Operating systems, application dependencies, containers, and other technical components are updated according to operational need, security relevance, and compatibility.

Critical issues can require updates outside a normal maintenance rhythm.

Acadex does not currently claim a fixed patching interval for every software component regardless of severity or operational context.

43. Change control

Changes to security-relevant application behaviour pass through the normal development and deployment process.

This includes version control, review, testing, and controlled deployment.

Changes to processing architecture, provider configuration, or data handling are also reflected in the relevant privacy and security documentation where required.

44. External services and subprocessors

Acadex uses external providers only for defined purposes.

The list of technically integrated services is not automatically identical to the list of subprocessors relevant to a particular institutional customer.

For model providers in particular, the actual processing chain depends on the provider profiles permitted for the account.

Institution-specific contractual documentation should therefore identify the processors that can actually receive personal data under that configuration.

External Services & Sub-processors →

45. Institutional restrictions

Institutional accounts can apply restrictions beyond the default consumer configuration.

Depending on the agreed setup, this can include:

• restricting model providers,
• restricting processing profiles,
• requiring particular geographic processing paths,
• disabling routes that do not meet institutional requirements.

These restrictions are intended to be technically enforced.

A user should not be able to bypass an institution-level provider restriction simply by selecting a different model.

46. Confidentiality

Persons with authorised access to personal data are required to treat that information confidentially.

Administrative access is limited according to role and operational need.

Personal data must not be used for unrelated personal or commercial purposes.

As the organisation grows, confidentiality and access obligations should remain part of onboarding and access-management processes.

47. No advertising use

Personal research content is not used to build advertising profiles.

Acadex does not sell conversation content, uploaded documents, memories, or research interests to advertisers.

The service does not currently rely on external advertising or behavioural analytics infrastructure.

48. Data-protection by design

Several Acadex design decisions are intended to reduce unnecessary data exposure.

Examples include:

• local embedding generation,
• separation of model-provider profiles,
• first-party Product Metrics,
• no external behavioural analytics,
• field-level encryption for selected sensitive content,
• restricted administrative access,
• separation of development and production,
• minimised context sent to external providers,
• account-linked deletion mechanisms.

These controls do not eliminate all privacy and security risk.

They are intended to reduce the amount of data exposed and the number of systems that need access to it.

49. Current limitations

Acadex currently does not have:

• individual-user multi-factor authentication,
• institutional SSO,
• a redundant multi-instance production deployment,
• a general uptime SLA,
• ISO 27001 certification,
• a SOC 2 report,
• a completed external penetration test,
• fully automated external 24/7 monitoring.

These are not presented elsewhere as already implemented controls.

50. Open operational parameters

The following operational values are still being finalised:

PostgreSQL backup frequency
[to be finalised]

PostgreSQL backup retention
[to be finalised]

regular PostgreSQL restore-test interval
[to be finalised]

regular formal TOM review interval
[to be finalised]

Once established, these values should replace the placeholders in the maintained version of this document.

51. Review of these measures

The measures described here are reviewed when material changes are made to the system, processing architecture, infrastructure, or security model.

A fixed recurring formal review interval is still being established during Early Access.

The intended review cycle is:

[to be finalised]

Security measures can also be reviewed outside that cycle where incidents, vulnerabilities, infrastructure changes, or new processing activities make this necessary.

52. Versioning

The Technical and Organisational Measures are versioned.

Each maintained version should identify the state of the controls it describes.

Institutional customers can therefore determine which version formed part of a particular contractual or security review.

Changes to the product do not retroactively change the contents of an older TOM version.

53. No certification claim

This document describes measures implemented by Acadex.

It is not an ISO 27001 certificate, SOC 2 report, penetration-test report, or independent security attestation.

Where independent assurance does not yet exist, we do not replace it with language designed to sound equivalent.

54. Questions and institutional documentation

If you are reviewing Acadex for an institution, we can provide additional information about:

• the applicable processing architecture,
• permitted model providers,
• institution-specific processing profiles,
• subprocessors,
• the Data Processing Agreement,
• security controls,
• and open implementation questions relevant to the proposed deployment.

Contact:

info@acadex.io

Related documentation

Security & Privacy →

External Services & Sub-processors →

Data Processing Agreement →

Privacy Policy →

Acadex for Institutions →