Compliance at RG INSYS LLP

Honest framing — read this first

Most agency websites list compliance frameworks as if they were trophies. We will not do that. Here is the plain-English position:

We design and deliver compliance-ready architecture. The systems we build for clients are engineered to meet the technical requirements of SOC 2, HIPAA, GDPR, and PCI DSS. Encryption, access control, audit logging, breach procedures, and data minimisation are baked in by default.

We do not currently hold active SOC 2, ISO 27001, or HIPAA "certifications" of our own corporate environment. SOC 2 Type 1 is in active progress, engaged with an auditor, target completion Q4 2026. ISO 27001 is on the roadmap for 2027. HIPAA is not a certification anyone can hold — there is only the Security Rule and a signed Business Associate Agreement (BAA), both of which we operate under when handling PHI on a client's behalf.

We sign BAAs and DPAs. Where the engagement requires it, we sign a Business Associate Agreement (HIPAA), a Data Processing Agreement (GDPR / UK GDPR / DPDP / PDPL), and any client-specific addenda. Our standard DPA template is downloadable.

If your procurement team needs a clean answer to "are you certified?", the honest answer is "not yet for SOC 2, working on it for 2026, here is what we deliver in the meantime." If that is a deal-breaker, please tell us early so we do not waste your team's time.

GDPR and UK GDPR

Our role. When we develop or operate systems on your behalf, RG INSYS LLP is typically a processor under Article 4(8). You are the controller. We process personal data only on your documented instructions, captured in the engagement Statement of Work and the DPA.

DPIA support. For new processing activities that require a Data Protection Impact Assessment under Article 35, we provide engineering input: data flows, retention, technical safeguards, and the residual-risk register. The DPIA is signed off by you as controller; we contribute the technical chapters.

Data subject rights workflow. Systems we build ship with a DSAR-ready data model: every personal-data field is tagged at design time, export and erasure routines are unit tested, and the API can produce a complete subject record on demand. Standard response window is 30 days from a verified request, with the optional 60-day extension supported.

Sub-processor list. Our current sub-processors are listed on the security page. Material changes are notified at least 30 days in advance, with a right of objection.

International transfers. India is not on the EU adequacy list, so EEA→India transfers rely on the EU Standard Contractual Clauses, Module Two (controller-to-processor), with the European Commission's June 2021 set. UK→India transfers use the UK International Data Transfer Addendum (IDTA) or the UK Addendum to the EU SCCs. Supplementary measures are documented per project: encryption in transit and at rest, access logging, refusal of bulk government requests in the absence of valid legal process, and notification to the controller of any such request that we are not legally barred from disclosing.

Article 32 technical and organisational measures. Encryption at rest (AES-256), encryption in transit (TLS 1.3), pseudonymisation where appropriate, access controls (RBAC + MFA), regular testing (SAST/DAST/pen test), and a documented incident response process. Listed in detail in our DPA Schedule 2.

Breach notification. Personal data breaches that are likely to result in a risk to data subjects are notified to the controller without undue delay and in any event within 72 hours of becoming aware, in line with Article 33(2). The notification template covers the nature of the breach, categories and approximate numbers of subjects and records, likely consequences, and measures taken.

HIPAA

Honest framing. "HIPAA certified" is not a thing. There is no government certification body. There is the HIPAA Security Rule (45 CFR §164.300), the Privacy Rule, and a signed Business Associate Agreement (BAA) between covered entities and their business associates. We operate under the Security Rule and we sign BAAs.

BAA available on request. When the engagement involves Protected Health Information (PHI), we sign your BAA or our standard one before any PHI is shared. Without a signed BAA, no PHI may flow to our team.

Technical safeguards (45 CFR §164.312).

Access control: unique user IDs, automatic logoff after 15 minutes idle, encryption and decryption of PHI at rest and in transit.
Audit controls: append-only logs of all PHI access, exports, and admin actions.
Integrity: checksums and write-ahead logging on PHI stores; tamper-evident audit trail.
Person or entity authentication: MFA required for any user accessing PHI.
Transmission security: TLS 1.3 with strict cipher suites, no PHI over unencrypted channels.

Administrative safeguards (45 CFR §164.308). Workforce security clearance, role-based assignment of access, periodic access review, sanction policy for violations, written security incident procedures, contingency plan, and recurring training. Documentation is provided to clients on request.

Physical safeguards (45 CFR §164.310). Production workloads run on cloud providers offering HIPAA-eligible services under their own BAA: AWS, Google Cloud, and Azure all maintain HIPAA-eligible service lists. We deploy only into eligible services when handling PHI. Workstation security is enforced via MDM and full-disk encryption.

What we do not do. We do not store PHI in non-HIPAA-eligible tools (Notion, Linear, Slack, Sentry public tier). Logs that may contain PHI are redacted at the edge before being shipped to non-eligible monitoring services; alternatively, monitoring runs entirely inside the HIPAA boundary.

SOC 2

Status. Type 1 readiness in active progress. We are engaged with a CPA firm and target completion in Q4 2026. We are not yet able to provide a SOC 2 report.

Trust Services Criteria implemented. Our internal control environment is being built against the AICPA 2017 Trust Services Criteria, focused on the categories most relevant to a software development partner:

Security (CC1 through CC9): control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, risk mitigation.
Availability (A1.1, A1.2, A1.3): capacity planning, environmental protections, recovery and backup procedures.
Confidentiality (C1.1, C1.2): identification and protection of confidential information; disposal procedures.

Policy bundle on request. We can share our information security policy, access control policy, change management policy, vendor management policy, incident response policy, and acceptable use policy under NDA. These are the same documents the auditor will review.

What we will not say. We will not call ourselves "SOC 2 ready" in a way that implies a completed audit. The report is the report; until we have one, we will say "Type 1 in progress" and nothing more.

PCI DSS

Our position is advisory only. RG INSYS LLP is not a merchant, not a payment processor, and not a registered service provider in the PCI DSS programme. We do not store, process, or transmit cardholder data on our own infrastructure.

What we do for clients. We design payment integrations to minimise the client's own PCI scope. The default pattern is tokenisation through a PCI-validated provider (Stripe, Adyen, Braintree, Worldpay) using hosted fields, Payment Element, or redirect flows. Cardholder data never touches the client's servers, which qualifies most clients for the lightweight Self-Assessment Questionnaire A (SAQ A).

Where the client requires a heavier scope (custom checkout, in-app card capture, server-side card processing), we advise on segmentation, key management, and audit logging requirements, and we will work alongside a Qualified Security Assessor (QSA) who is engaged to perform the formal assessment.

If you specifically need a partner who is themselves a PCI Level 1 service provider, we are not that partner — and we will tell you that on the first call.

DPDP Act 2023 (India)

India's Digital Personal Data Protection Act 2023 introduces consent-based processing of digital personal data, with the Data Protection Board of India as the regulator. As an Indian company we are directly subject to the Act, and we operate as a Data Processor on behalf of clients who are Data Fiduciaries.

Consent management. Systems we build implement granular, withdrawable consent capture and a consent log per data principal.
Data fiduciary obligations awareness. Where the client is the Data Fiduciary, we provide engineering support for the obligations under section 8: notice, accuracy, retention, security, and breach reporting.
Breach notification. The Act requires notification of personal data breaches to the Board and affected principals. We support clients in meeting the 72-hour notification window with pre-built notification workflows and breach assessment runbooks.
Children's data. Where the system processes the data of children (under 18 in India), we implement verifiable parental consent flows and disable behavioural tracking by default.
Cross-border transfers. The Act allows transfers to countries except those notified by the Government as restricted. Our infrastructure choices respect any client-specific localisation requirements.

UAE PDPL and free-zone regimes

For UAE-based clients we work under Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data, supplemented by the executive regulations issued by the UAE Data Office. Where a client is incorporated in a financial free zone, we also align with the local data protection regulation:

ADGM: Abu Dhabi Global Market Data Protection Regulations 2021.
DIFC: Dubai International Financial Centre Data Protection Law (DIFC Law No. 5 of 2020).

Both ADGM and DIFC regimes are GDPR-aligned, so the same technical and organisational measures apply: lawful processing, consent and legitimate interest assessments, data subject rights workflows, transfer mechanisms, and breach notification within the regulator-defined window.

We have delivered systems for clients regulated by the UAE Central Bank, Dubai Health Authority, and free-zone-licensed entities, and we are familiar with the procurement and security questionnaires those regulators issue.

Standard DPA template

Our standard Data Processing Agreement is available for download as a starting point for legal review. It includes Schedule 1 (subject matter and duration of processing), Schedule 2 (technical and organisational measures), Schedule 3 (sub-processor list), and Annex I to the EU SCCs.

We are happy to work from your DPA template instead. We have signed many of them, including those of UK NHS trusts, US health systems, large UK recruitment groups, and UAE financial-services clients.

Download DPA template →

Compliance — what we actually do, what we do not