Security and compliance

01Our position, stated plainly

This page describes that accountability honestly, including where it ends. If a vendor questionnaire asks us something this page does not cover, ask us directly rather than assuming the answer.

02Shared responsibility

Security in an integrated system is divided three ways. Confusion about which party owns which control is, in our experience, the most common cause of a gap.

03Access and credentials

How we get into your systems is the part of this we control most directly, so we are strict about it.

• Your accounts, not ours. Wherever the platform supports it, accounts are opened in your name and we are added as a user. We do not hold your business hostage inside an account we own.
• Least privilege. We request the narrowest role that lets us do the work, and we ask you to reduce or revoke it when a phase completes.
• Named individuals. Access is granted to named people on our team, never to a shared login. Multi-factor authentication is required on every account that supports it.
• Secrets management. API keys, tokens, and credentials are stored in a dedicated secrets manager. We do not keep them in spreadsheets, chat messages, code repositories, or email. If you send us a credential in plain text, we will move it and ask you to rotate it.
• Prompt revocation. When someone leaves our team, their access is revoked the same day. At the end of an engagement we confirm in writing which access should be removed, and we ask you to verify removal at your end.
• Rotation on handover. We recommend rotating any credential we have held once an engagement ends. We will remind you.

04Data handling

• Minimisation. We design integrations to pass the fields a workflow actually needs, rather than mirroring entire records because it is easier.
• Residency. Where you need data to stay in a specific region, tell us before build. We will select platforms and regional configurations that support it and confirm what is achievable. Not every platform offers every region, and we will tell you where a requirement cannot be met.
• Production data in development. We do not copy production personal data into development or test environments. We use synthetic or anonymised fixtures.
• Local copies. Where analysis requires a data extract, such as sampling call recordings during an audit, we agree the scope in writing, hold it only for as long as the analysis needs, and delete it afterwards.
• Retention. Retention inside a client system is a configuration decision we make with you and document. Transcripts, recordings, and logs are frequently the highest-risk data in a voice deployment and deserve an explicit decision rather than a default.
• Deletion. On instruction or at the end of an engagement we delete or return data we hold as processor and confirm when it is done.

05Platforms and sub-processors

Every client system depends on third-party platforms. The specific list for your engagement is documented in your statement of work, and each of these is a sub-processor for data protection purposes. Typical categories:

We select platforms that hold the certifications your sector requires and we will share their compliance documentation on request. We will give you reasonable notice before introducing a new sub-processor to a live system, and you may object.

06People and devices

• Everyone on our team is bound by written confidentiality obligations that survive their employment or engagement.
• Access to client systems is limited to team members working on that engagement.
• Working devices carry full-disk encryption, automatic screen lock, and current operating system and security updates.
• Team members receive security and data protection briefing on joining and refreshers thereafter, covering phishing, credential handling, and client data hygiene.
• Where an engagement requires background checks or specific training, tell us during scoping and we will arrange it.

07How we build and deploy

• Configuration and integration logic is kept under version control with a documented change history.
• Development, staging, and production are separated. Changes are tested before they reach production traffic.
• Changes to a live client system follow an agreed change process, with a rollback plan for anything material.
• Workflows ship with error handling, retry logic, and alerting. A silently failing automation is a security and operational risk, not just an inconvenience.
• Voice and chat agents are tested adversarially before launch, including attempts to extract system instructions, to obtain answers on restricted topics, and to bypass escalation rules.
• Dependencies are reviewed and updated on a regular cycle.

08Incidents and breach notification

If we become aware of a security incident affecting your data or a system we operate for you, we will:

1. Contain it and preserve what is needed to understand what happened
2. Notify you without undue delay, and in any event within 24 hours of confirming an incident affecting your data
3. Tell you what we know, what we do not yet know, and what we are doing about it, then keep you updated as the picture changes
4. Support you in meeting your own notification obligations, including to the Data Protection Board of India under the DPDP Act, to supervisory authorities under the GDPR, and to affected individuals
5. Provide a written post-incident report with root cause and corrective actions

Where an incident originates with a platform provider, our role is to alert you, assess your exposure, and coordinate. The provider's own notification obligations run to you as their account holder.

As the Data Fiduciary in most arrangements, the statutory notification duty is generally yours. We support it. We do not discharge it for you.

09Compliance frameworks, and what we do and do not claim

What is true of the platforms

The platform providers we deploy on hold their own independent certifications, commonly including SOC 2 Type II and ISO 27001, with HIPAA-eligible configurations and GDPR commitments available from several. Where your sector requires a specific certification, we select platforms that hold it and provide their attestation documents during scoping.

What is true of Sciquire

We align our own internal practices to the control areas these frameworks describe: access control, least privilege, secrets management, change control, personnel screening and training, incident response, and data lifecycle management. This page describes those practices.

What we do not claim

Unless we have given you a current attestation report naming Sciquire AI Solution LLP, we are not asserting that Sciquire itself holds SOC 2, ISO 27001, or HIPAA certification. If a certification of the agency rather than the platforms is a procurement requirement for you, raise it early and we will tell you honestly where we stand and what timeline is realistic.

Indian law

We operate under the Digital Personal Data Protection Act, 2023, and the Information Technology Act, 2000, together with the rules made under them. Where we act as processor we do so under a written agreement with the client as Data Fiduciary. Where outbound calling or messaging is involved, TRAI's TCCCPR framework applies and is addressed in our terms of service.

10Continuity

• Client configurations, workflow definitions, and documentation are backed up so an engagement is not dependent on one person or one machine.
• Because platform accounts are held in your name and configurations are handed over documented, you are not exposed to Sciquire as a single point of failure. This is deliberate.
• Where a client system is business-critical, we agree an escalation contact and out-of-hours arrangement in the support plan rather than leaving it to chance.
• Platform outages are handled through the fallback behaviour agreed at design time, such as routing calls to a human queue when an agent cannot be reached.

11Reporting a vulnerability

If you believe you have found a security issue in this website or in a system we operate, tell us at [email protected] with the subject line "Security". Include enough detail to reproduce it.

We will acknowledge within two working days, keep you informed while we investigate, and credit you if you would like to be credited. We ask that you give us reasonable time to fix an issue before disclosing it publicly, and that you avoid accessing or modifying data that is not yours while testing. We will not pursue action against anyone acting in good faith under these terms.

12Due diligence and audits

We are happy to support your procurement process. On request we will complete a reasonable security questionnaire, provide platform compliance documentation, sign a data processing agreement including standard contractual clauses where the GDPR requires them, and walk your security team through the architecture of a proposed system.

Where your contract with us includes audit rights, we will cooperate with a reasonable audit on reasonable notice, no more than once a year unless there has been an incident. Audits of platform providers are a matter between you and them, and we will point you at the right documentation.