Security Architecture and Judicial-Portal Integration

Last updated: 12 August 2026 · Version: 1.0Ελληνική έκδοσηDownload PDF (EL/EN)

This page provides a technical overview of the security boundaries used by CourtSync when handling judicial-portal credentials, interacting with supported judicial information systems, and processing case-related data.

For contractual and data-protection terms, see the Terms of Service, Privacy Policy, and Data Processing Agreement.

This page is a public architectural overview, not a complete disclosure of internal security configuration. To reduce security risk, it describes control objectives and processing boundaries rather than internal topology, source-code structure, secret identifiers, or specific operational thresholds. It does not create a service-level agreement, certification, or warranty beyond the Terms of Service and Data Processing Agreement.

The Greek and English versions are intended to have the same meaning. If they differ, the English version prevails.

1. Processing boundary

CourtSync separates data according to the role in which Hartwell Legal Systems processes it:

  • account, subscription, support, security, and consent data is processed by Hartwell to operate CourtSync, as described in the Privacy Policy;
  • judicial-portal credentials, case identifiers, retrieved procedural information, monitoring history, and related data are processed on the customer's instructions, as described in the Data Processing Agreement; and
  • operational metadata, such as connection status and check timestamps, is retained only as required to operate, secure, and support the enabled feature.

CourtSync processes portal credentials and case information only for features and cases selected or authorised by the customer.

2. Credential protection

Judicial-portal passwords are encrypted at the application layer before persistence. The corresponding cryptographic material is managed separately from encrypted credential records through dedicated key- and secret-management infrastructure.

The design separates stored encrypted credentials from the capability required to use them. Access to the application database alone is therefore insufficient to recover a usable portal password.

Portal passwords are not stored in browser-side application code and are not returned to the browser after submission.

3. Credential-access boundary

General user-interface and API flows do not expose stored judicial-portal passwords. Runtime use is restricted to the authorised processing context that carries out the customer's instruction against the relevant judicial portal.

Portal passwords are excluded from application logs, billing and account-management systems, analytics and session-replay tools, and support notifications. A failed credential-verification notice may identify the portal username so that the customer can detect an incorrect account; it does not include the password.

4. Customer-authorised portal operations

The current monitoring integration uses credentials supplied by the customer to access olomeleia.gr on the customer's behalf. The same control model applies to any future supported judicial portal.

CourtSync limits portal activity to cases, identifiers, and actions selected or enabled by the customer. It does not use the customer's credentials to inspect unrelated cases or for an independent Hartwell purpose.

New or modified credentials are verified before they become operational. Monitoring a case does not authorise a filing, submission, or other procedural act. Any future transmission or electronic-filing capability will require an explicit customer instruction through the relevant feature.

5. Judicial-portal interaction policy

CourtSync is designed as a targeted monitoring client, not as a general-purpose crawler or bulk-indexing system. Its interaction model applies controls including:

  • case-specific queries limited to customer-selected matters;
  • bounded scheduling and request frequency;
  • request pacing and load-limiting controls;
  • reuse of an authenticated session where technically appropriate;
  • account- and case-level operational limits; and
  • out-of-schedule checks only following an explicit customer action.

These controls are intended to reduce repeated authentication and unnecessary request volume while maintaining the monitoring functionality selected by the customer.

Hartwell is available for technical coordination with judicial-system operators, including official API access, approved system-to-system integration, or participation in official interoperability programmes where available.

Further information on operational access controls and coordination with portal operators is available in the Judicial-Portal Access Policy.

6. Analytics and session-replay isolation

With user consent, CourtSync may use analytics and session-replay tools to understand interaction with the interface and improve usability. These tools are kept outside the judicial-data processing path.

Credential fields, case identifiers, party or client names, judicial and procedural content, documents, uploaded files, free-text entries, notification content, and other sensitive customer data are masked or excluded before transmission. Only low-risk interface elements and pseudonymous technical identifiers may be used for product analysis.

The current providers, purposes, consent controls, and retention information are described in the Privacy Policy. Where a provider is permitted to process personal data on a customer's behalf, it is treated as a subprocessor under the Data Processing Agreement.

7. Deletion and data lifecycle

Disconnecting a judicial portal removes the active credential from CourtSync's operational data store rather than merely disabling it.

Encrypted residual copies may remain temporarily within managed recovery or backup mechanisms until the applicable lifecycle expires. Such copies remain encrypted and are not used as active credentials.

Return and deletion of other customer personal data are governed by the Data Processing Agreement and available CourtSync functionality.

8. Infrastructure, transport, and access control

CourtSync primarily processes Service data within the European Economic Area using managed cloud infrastructure. The categories of core subprocessors and their general processing locations are listed in the Data Processing Agreement; the named list is available on request.

Security controls include encrypted transport for browser, service, database, and supported-portal communications; separation of application data from managed keys and secrets; least-privilege service access; logical separation between customer workspaces; restricted production access; and security and infrastructure logging.

The security architecture is reviewed when material changes are made to the Service or its processing model.

9. Security and integration contact

Questions about CourtSync security, suspected vulnerabilities, or the handling of judicial-portal credentials may be sent to support@courtsync.gr.

Judicial-system operators and institutional stakeholders interested in official API access, supported integration, or technical coordination with CourtSync may use the same address.