Terminology
Personal Identifiable Data (PID) - Also called Personal Identifiable Information (PII)
The basic definition of personal data is any information relating to an identified or identifiable natural person (data subject).
Examples include the following list and often require being combined with other items in the list. For example, knowing the Gender of a Resource in a database is not Personal Identifying unless it is also possible to combine that information with a Name, Address, etc.
- Name and surname
- Email address
- Phone number
- Home address
- Date of birth
- Race
- Gender
- Political opinions
- Credit card numbers
- Data held by a hospital or doctor
- Photograph where an individual is identifiable
- Identification card number
- A cookie ID
- Internet Protocol (IP) address
- Location data (for example, the location data from a mobile phone)
- The advertising identifier of your phone
PID includes data that has been encrypted, archived, or otherwise obfuscated, if it is possible to recover the source PID. This includes pseudonymized data (e.g., tokenized or reversibly encrypted data), which remains classified as PID under GDPR. Only irreversible anonymization removes data from PID scope.
Not included in the scope of PID is information that is properly and irreversibly anonymized (i.e., not recoverable to the source PID), or information about public authorities and companies.
Client Data
Client-supplied data that contains information used in Xytech software. This includes any Client data in any format such as spreadsheets, databases, text files, etc. which comes from or is intended for use in Xytech software.
Client Data often contains PID such as contact and additional information for employees, contractors, vendor employees, and client customer contacts.
Client Data is different from Client Information.
Client Information
Information about Fabric Clients such as their address, contacts, and licensed software. This is information that Fabric uses to operate our business and work with our clients. Client Information is NOT considered in this Policy.
Client Data Transfer
The act of moving Client Data from the Client to Fabric through support, professional services, or other processes that is NOT done through the direct use of Xytech Software.
Examples include:
- Client provides a copy of their production database
- Client provides spreadsheets of their data to Fabric personnel for analysis and/or services such as mapping into Xytech Software
- Client provides text files
- Client uploads files via the Fabric upload portal
The method of transfer such as using FTP, email, upload portal, or other means does not matter, only that Fabric receives the data.
Data Sovereignty
The policies and laws for a country or jurisdiction which has the authority and right to govern and control the data generated or processed within its borders or on its infrastructure.
Key frameworks relevant to Fabric:
- EU GDPR: Governs processing of EU residents' personal data. Restricts transfers of PID outside the EEA unless an adequate level of protection is ensured through an adequacy decision, Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), or other approved mechanisms.
- UK GDPR: Applies to data of UK residents. The UK maintains its own adequacy framework under the Data (Use and Access) Act 2025 (DUAA) and issues its own adequacy decisions for transfers to approved countries.
- US State Laws (CCPA, CDPA, etc.): Regulate transparency, consumer rights, and data handling practices. These laws do not restrict where data may be stored geographically or prohibit cross-border transfers.
Note: Adequacy decisions between jurisdictions are periodically reviewed and may change. Always confirm current adequacy status with your legal or DPO contact before relying on them.
Jurisdictions and Data Location
For Fabric Cloud Hosting, data sovereignty jurisdiction is determined primarily by where data is stored and processed, not solely by where the client is located. When a client uploads data to a Fabric-hosted endpoint, the governing jurisdiction is that of the server location, and the laws of that jurisdiction apply to how the data is handled from that point forward.
Fabric currently operates a single upload endpoint hosted in Paris, France (EU jurisdiction). The following applies per client region:
- EU/EEA Clients: Data uploaded to the Paris endpoint remains within EU infrastructure. No cross-border transfer occurs and no additional transfer mechanism is required. GDPR applies directly.
- UK Clients: The EU's adequacy decision for the UK was renewed in December 2025 and is valid through December 2031. UK-to-EU data flows (a UK client uploading to Paris) are permitted without additional safeguards under the current framework. UK GDPR governs data of UK residents regardless of where it is processed.
- US Clients: US state privacy laws do not restrict data from being stored outside the United States. There is no US legal blocker for US clients uploading to the Paris endpoint. However, once that data is stored on EU infrastructure, GDPR governs its handling.
A separate regional upload link for US, UK, or EU clients is not required under the current architecture and adequacy framework.
Staff Access to EU-Hosted Data
Access by non-EEA staff (including US-based support and engineering personnel) to data stored on EU infrastructure can itself constitute a transfer under GDPR, regardless of whether the data physically moves. This applies even when the file originates from a non-EU client.
- All non-EEA staff access to EU-hosted data must be documented in the applicable Data Processing Agreements (DPAs)
- Access should be limited to what is necessary for the specific support or operational task
- Any access for troubleshooting or testing must follow the principle of data minimization
Client Data Handling Policies
Data Sovereignty Policy
No Fabric Employee shall, nor induce or cause a Client to, move Client Data that contains PID from the data source jurisdiction to another jurisdiction, except where a lawful transfer mechanism is in place and documented.
Client Data that does not contain PID should not be moved from the source jurisdiction to another jurisdiction without the express written consent of the Client providing the data. That consent must include the identification of the source and destination jurisdictions and the Client should state that they have removed all PID from the data prior to transferring that data to Fabric.
In practice, this means:
- On-Premises Client databases transferred to Services, Support, or another Fabric department should have the PID obfuscated before the database is moved or copied from the Client's system to a Fabric services or support system
- Fabric Hosted Systems client databases should not be transferred from the EU or any other Data Sovereignty Jurisdiction to the US (or any other jurisdiction) if that database includes PID
- If a client provides production data (spreadsheets, file imports) that includes PID, that data must remain in the source jurisdiction unless properly anonymized and written consent is obtained
Best practices include the following in priority order:
- All Client Data NOT in a hosted Client production or Client test system shall have the PID anonymized
- If a client has stored additional PID in Xytech product's custom data fields, it is the responsibility of the client to inform Fabric which custom fields they have used so Fabric can provide assistance and utilities to support the data being anonymized
- If a client provides production data to import into the Xytech software using spreadsheets or other file formats and that data includes PID, it must remain in the source jurisdiction
- Any work (testing, querying, etc.) performed on Client Data that is not a Client Production or Client Test system should be performed in the jurisdiction in which the data was created. E.g., if testing features against a client's database is required, that should happen in the cloud hosting location in which the source data was created
- If transfer of a database copy to another jurisdiction is required, the PID data must be anonymized in the source data jurisdiction before the data is transferred and we must get written permission from the client
Client Data Management
Client Data not in Fabric hosted Client Production or Client Test systems should be destroyed once the data is no longer required. This includes the source of the Client data such as a database backup file (.BAK, .ZIP, .7Z, etc.).
Client Data required for long-term usage such as regression testing must have the PID anonymized, and the Client Data should be managed under our IT security policies to reduce risk of the Client Data being accessed without reason and permission.