Compliance Posture

Parascope is not yet certified. This page states that first, then does the thing an uncertified vendor can usefully do: map the controls we operate and publish onto the criteria your framework asks about, so your review can work from evidence you are able to check. The control matrix carries the same mapping as a filterable table; this page is the prose version, framework by framework.

Status

Parascope is not yet SOC 2 or ISO 27001 certified. No third-party audit has been performed against either framework; there is no report or certificate to send you today, and a questionnaire row asking whether we hold one gets a no. Certification is planned, but not yet scheduled. The platform is designed and built for these frameworks: the controls this page maps are operated and documented against the criteria they audit, so a future audit examines what already exists.

GDPR is a regulation with no certificate to hold. Parascope Limited acts as a processor for the data in your tenant, and the GDPR section below describes how that role is met.

PCI DSS is out of scope for the platform. Card details are entered on Stripe's hosted checkout, and the platform stores Stripe customer and invoice identifiers only.

Security at Parascope gives the same status alongside the rest of the security picture, including who operates the platform. This page goes deeper on the framework mapping.

How to read the mapping

Each control in the matrix carries one or more framework tags. A tag says the control addresses that criterion: it is the kind of control the criterion asks for, operated today, and described in enough detail for you to check it yourself. A tag is not a compliance attestation. Nobody outside the company has examined this mapping, and we wrote it from the controls we run.

So a row saying a control addresses CC6.1 means we operate logical access controls of the sort CC6.1 describes and have written down how they work. It does not mean an auditor tested them.

The mapping is also where the gaps are visible. Several criteria have honest answers on this page that a vendor who had been through an audit would answer differently, and those answers are stated in the sections below in the same terms as the ones that go our way.

SOC 2 Trust Services Criteria

CC2 and CC3, communication and risk. This documentation corpus is the control. It publishes without a login or an email form, and it covers the places where a control stops or does not exist. Accepted vulnerability findings and the decision recorded against each one are in Vulnerability Management.

CC6, logical and physical access. This is the densest part of the corpus. Tenant Isolation Architecture describes what is dedicated per tenant and what is shared. Access Control and Authentication covers permissions, API key tiers, MFA scope, and the audit log. Encryption in Transit and at Rest states which data is encrypted under which algorithm and where at-rest coverage stops.

CC7, system operations. Detection, response, and the containment path are in Incident Response, which also carries the severity definitions and the response times one operator commits to. Finding and patching vulnerabilities is in Vulnerability Management. Platform incidents are posted publicly to parascope.instatus.com.

CC8, change management. Software Supply Chain documents what has to pass before a change can merge, how production images are signed, how a release reaches production as an immutable image SHA, and what the pipeline leaves unchecked.

CC9.2, vendor and business partner risk. Subprocessors names each third party engaged to run the service, what it can see, where it sits, its transfer mechanism, and the 30-day notice served before that list changes.

A1, availability. Availability, Backups and Disaster Recovery sets out the availability target and its definition, the backup layers, what the weekly verification job proves, and the recovery targets the platform is designed against.

C1, confidentiality. Encryption in Transit and at Rest covers protection of stored and transmitted data. Data Handling and Retention covers the other half of C1: how long each record is kept and how it is disposed of, including what a tenant deprovisioning deletes.

Where this posture answers weakly. The organisational criteria are the ones to read closely. CC1 asks about a control environment with defined roles and oversight, and CC4 asks who monitors the controls. One person operates Parascope, so there is no segregation of duties and no internal audit function. The compensating controls a single operator can run are set out under "Who operates Parascope" in Security at Parascope, and a reviewer should weigh them for themselves.

ISO 27001 Annex A

A.5, organizational controls. Policies for information security (A.5.1) are addressed by the statements published on what tenants share in Tenant Isolation Architecture and on where at-rest encryption stops in Encryption in Transit and at Rest. Identity management (A.5.16) is addressed by Tenant Isolation Architecture, which describes the identity realm each tenant gets. Access control, authentication information, and access rights (A.5.15, A.5.17 and A.5.18) are addressed by Access Control and Authentication. Supplier relationships (the A.5.19 to A.5.23 range) are addressed by Subprocessors, which names each third party, its role, what it can see, where it sits, and the 30-day notice before that list changes. Information security incident management (A.5.24 onward) is addressed by Incident Response. Information security during disruption and ICT readiness for business continuity (A.5.29 and A.5.30) are addressed by Availability, Backups and Disaster Recovery, which carries both the availability target and the recovery targets. Privacy and protection of personal data (A.5.34) is addressed by Data Handling and Retention.

A.6, people controls. Parascope Limited has no employees. Screening, terms of employment, awareness training, and the disciplinary process have no subject to apply to, so these controls are answered "not applicable, no personnel". If headcount changes, this section changes with it.

A.7, physical controls. The platform runs on Hetzner Cloud in Helsinki, Finland. Physical security of the facility is the data centre operator's to attest. Parascope operates no data centre and no office estate of its own.

A.8, technological controls. Privileged access rights (A.8.2) and restriction of access to information (A.8.3) are addressed by Access Control and Authentication, which also covers logging (A.8.15) through the tenant audit log. Use of cryptography (A.8.24) is addressed by Encryption in Transit and at Rest. Information backup (A.8.13) and redundancy (A.8.14) are addressed by Availability, Backups and Disaster Recovery. Management of technical vulnerabilities (A.8.8) is addressed by Vulnerability Management. Secure development, change management, and the separation of environments (A.8.25 onward) are addressed by Software Supply Chain.

Where this posture answers weakly. An ISO 27001 audit turns on the management-system clauses (4 to 10) more than on Annex A itself, and those are where a single-operator business is thinnest: there is no documented ISMS scope, no management review cycle, and no internal audit programme. The Annex A mapping above stands on its own as a description of operated controls.

GDPR

Roles. You are the controller for the data you put in Parascope. Parascope Limited is your processor and engages the subprocessors listed in Subprocessors. Hosting and the primary data stores are in the EU, in Helsinki. The transfers outside the EEA, each with its mechanism, are listed in Subprocessors: the offsite backup mirror at Cloudflare, HTTP request metadata (IP addresses and headers) passing through the Cloudflare global edge in transit, billing at Stripe, transactional email at Postmark, and the language model provider used by the AI features, which processes in the USA under standard contractual clauses; AI Features and Your Data traces exactly what text reaches it.

The data processing agreement. A DPA is available on request from privacy@parascope.io. The document is in legal review, so its terms may change before it is signed, and no customer agreement has been executed against it yet. Ask for it early in your review and tell us what your legal team needs to see, because that feedback is useful while the text is still open.

Access requests. A full tenant export is available in the product at Settings → Account → Data Export, producing structured JSON covering configuration items, relationships, change history, and configuration, with the user records from your identity realm included on request. Security events are exportable as CSV from Settings → Audit Log. Data Handling and Retention documents both paths and the retention windows around them.

Erasure requests. Deleting a tenant runs a deprovisioning workflow that drops the tenant database, deletes the message streams and messaging account, deletes the identity realm, and removes export objects. One residue is worth knowing about before you rely on it: rows already captured in encrypted backup copies survive until those copies age out. Data Handling and Retention describes the workflow and that residue in full. Erasure requests go to privacy@parascope.io. The backup residue is the answer rather than a starting position: copies are not edited to remove individual records, the copies age out on the retention schedules Data Handling and Retention describes, roughly ninety days at the outside, and nobody lifts the bucket lock that protects the off-provider copies to beat that clock. A request that reaches us directly from one of your users is passed to you, since the controller answers it.

Breach notification, Article 33(2). A personal data breach is reported to you without undue delay and no later than 72 hours after we become aware of it, covering the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken or proposed. That is the processor-to-controller clock. Notifying your supervisory authority is the controller's duty and runs on its own 72-hour clock, and our commitment is sized so that clock is not spent waiting on us. Incident Response carries the severity definitions and the notification path.

Subprocessor transparency, Article 28(2). The subprocessor list is published on this site with no request needed, and adding or replacing a party means emailing tenant administrators 30 days before that party begins processing your data. You can object inside the window, and an objection we cannot resolve between us lets you terminate the subscription.

Getting a questionnaire answered

Send security questionnaires to security@parascope.io. Answers come from these pages, with the section that carries each answer cited on the row, so your file shows where each response came from. Rows we cannot answer with a yes get a no and the reason, which is the same standard the rest of this corpus is written to.

Data protection questions and DPA requests go to privacy@parascope.io. Commercial questions go to hello@parascope.io.

Verify it yourself

• Filter the matrix by framework. Open the control matrix and filter to the criterion your review turns on. Each control names how to verify it.
• Check a control without asking us. Software Supply Chain gives the command that verifies a production image signature. Access Control and Authentication shows how to find your own actions in the audit log. Data Handling and Retention shows the export path in the product.
• Confirm the operating company. Parascope Limited is registered in Dublin under CRO number 810646, searchable on the Irish Companies Registration Office register at core.cro.ie.
• Watch the availability record. The status page at parascope.instatus.com is hosted independently of the platform it reports on, so an outage does not take the incident history with it.
• Ask for the DPA. privacy@parascope.io. It arrives as the document described above, in legal review, with no claim attached that it has been signed by anyone yet.