Security & operations

Security is implemented as a layered combination of architecture, access control, operational controls, and continuous monitoring rather than as a single technical component.

Each customer solution is deployed in an isolated customer environment in Amazon AWS (EU/Ireland), with separate application environments, database/storage resources, source-code/CI/CD repositories, and controlled access boundaries. External access is protected through managed HTTPS/TLS endpoints and AWS network/edge controls, including CloudFront and AWS WAF where applicable, together with load balancing and controlled network access.

At application level, access is controlled through authentication and authorisation, role-based access control (RBAC), and least-privilege permissions. SSO and MFA can be enabled where required. Business data and private files are not anonymously accessible; file access is controlled through authorised/signed access mechanisms, and credentials and secrets are kept in restricted secret-storage systems.

Development and production operations are separated across test, staging, and production environments. Production changes are delivered through controlled CI/CD pipelines with traceable source history, review, testing/regression, and auditable releases. The environment is continuously monitored and logged, with automated alerting, backups, and database point-in-time recovery. Normal security, framework, and compatibility updates required to keep the solution current are part of ongoing Maintenance and SLA.

Yes. ReApptor-based production applications have gone through several independent security audit and review cycles. Our largest healthcare production application has been subject to multiple independent security audits. The latest audit was carried out at the end of 2025, and the resulting recommendations were reviewed, implemented, and subsequently released into production.

If the customer would like an independent security audit of its own solution, ReApptor is fully prepared to support it. The audit scope can include the application, solution architecture, AWS environment, access controls, and other agreed security areas, and can be carried out by an independent third-party security auditor.

A customer-specific external security audit is not included in the standard development, licence, Maintenance, or SLA fees. Audit preparation, independent auditor fees, and any audit-specific work are agreed separately, as the scope and cost can vary materially depending on the required depth.

Security findings are managed through the same controlled engineering and release process as other business-critical changes. Findings are assessed by severity and business impact, prioritised in the development/maintenance backlog, implemented and tested in non-production environments, and then released to production through the controlled deployment process.

Security updates required to maintain the existing agreed functionality and keep the solution technically current are part of ongoing Maintenance and SLA. A separately commissioned external audit is an independent verification activity; remediation of normal security and compatibility issues is handled according to the applicable Maintenance scope, while material changes or new security capabilities outside the agreed scope are handled through the normal Work Order process.

Each customer runs in an isolated environment with strict access boundaries:

• Separate source code, CI/CD repositories per customer, per application
• Separate application environment per customer, per application
• Customer-specific storage buckets/paths for files
• Role-based access control (RBAC) inside the application so users only see what their role and organisation allow

We ensure GDPR alignment through standard controls and operating practices:

• EU data residency (EU regions, eu-west-1, Ireland)
• Access control and least-privilege permissions
• Auditability (traceable changes and access logs)
• Defined data retention and deletion procedures (customer-controlled policies)
• Processor/controller roles and data-processing responsibilities clarified in writing (ReApptor acts as a processor for customer data unless otherwise agreed)

In the agreed cloud environment (Amazon AWS), in an EU region (eu-west-1, Ireland):

• Relational database for structured data (MySQL/Aurora)
• Object storage for files (drawings and documents) with controlled private role-based access (S3)

The ReApptor solution maintains its own complete and consistent representation of the business data required for the processes it manages.

Data from external systems can be automatically copied, synchronised and updated without requiring users to manually transfer the same information between different tools.

The objective is not only to eliminate manual copying of customer, product, order, project or supplier information, but, wherever possible, to reduce manual data entry itself through integrations and automation.

External systems may remain important tools and data sources, but the core ReApptor solution is designed to remain complete and operational without depending on any individual external application.

We operate with production-grade operational safeguards:

• Automated backups with defined retention
• Point-in-time recovery for databases
• Disaster recovery procedures and documented restore processes
• Monitored infrastructure with alerting to detect failures early

Exact RPO/RTO targets depend on the SLA level (Standard, Expanded).

Support is handled through a structured, tool-driven process:

• Centralised ticketing and triage
• Proactive monitoring and alerting
• Controlled releases via test/staging/production environments with rollback
• Severity-based incident handling with clear ownership and escalation paths

We also have an agreed arrangement with WeAre Solutions for IT Helpdesk / technical support capability (including aligned tooling and processes), which strengthens coverage during growth.

We prioritise by severity and business impact (production outage and critical incidents first). Because operations are standardised, engineers can switch context efficiently between customer environments. If needed, we reinforce capacity using partner resources while keeping incident coordination and ownership clear.

We assess reliability through monitoring and incident history. Availability commitments are defined in the agreed SLA.

Automation and controlled release and incident processes support operational reliability; service commitments are defined in the agreed SLA.

Confidential business information — such as product development, customer lists, partner information and financial information — is used only for the agreed cooperation and protected against unauthorised disclosure.

Personnel and subcontractors receive only the information they need for their work, under confidentiality commitments.

When cooperation ends, the use of the other party's confidential information stops and the material is returned or handled as agreed. Processing of personal data is covered by separate data processing terms.