Security
Last updated: 21 September 2026
PILLAR holds passports, visas, family details and immigration paperwork, so the people who run it have to be able to see how it is protected. This page says what is in place today, in plain words, and it says what is not.
PILLAR Relocation ApS is not itself certified to ISO 27001 or SOC 2. We design and run the platform with GDPR and ISO 27001 principles in mind, and the providers that host and process the data hold their own certifications, which are listed at the end of this page. We will not describe a certification as ours until we hold it.
Where PILLAR runs
Section titled “Where PILLAR runs”PILLAR runs on Microsoft Azure in the Sweden Central region, inside the EU. The application, the database, file storage, the cache and the sign-in service all sit there. Database backups are copied to Azure’s paired region, Sweden South, also inside the EU. AI processing stays within Microsoft’s EU Data Boundary (the EU plus EFTA countries such as Norway and Switzerland).
Systems security
Section titled “Systems security”The physical and network security of the data centres, the hardware, and the underlying cloud platform is provided by Microsoft Azure, which is independently audited to ISO/IEC 27001 and SOC 2 Type 2. Our own application runs in Azure Container Apps. It connects to its database under a managed identity rather than a password, and application secrets such as API keys are held in Azure Key Vault, never in configuration files.
Application security
Section titled “Application security”Each customer is kept separate. Every customer record belongs to exactly one customer organisation, and every query made on behalf of a user is limited to that user’s organisation. This is enforced in the data layer, not left to each screen to remember. Crossing that line is treated as a defect.
Every action needs a named permission. Each screen and each API call a signed-in user makes is gated by a specific permission, and permissions are grouped into roles: platform administrator, organisation administrator, case manager, agent, transferee and employer. Visibility goes further than roles — case assignment, task ownership and document classification decide who sees what. Employers do not see a transferee’s passport, visa, date of birth, nationality, health or financial details; transferees do not see internal notes; agents see only what they are assigned.
Sign-in. Sign-in runs on Keycloak, open-source identity software that we operate ourselves inside Azure. Customers can sign in with their Microsoft or Google work accounts (single sign-on), or with a password. Two-factor authentication is enforced for every password sign-in to the PILLAR app: a user is enrolled with an authenticator app and recovery codes during their first sign-in and challenged on every sign-in after that. Users who sign in through their organisation’s Microsoft or Google directory follow that directory’s own sign-in policy.
The AI assistant follows the same rules. It can only reach the data the signed-in user is allowed to see, and every change it proposes waits for that user to approve it.
Data security
Section titled “Data security”In transit. All traffic between your browser and PILLAR, and between PILLAR and the external services it uses, is encrypted with TLS. The database accepts TLS 1.2 or later only.
At rest. The database is encrypted as a whole with Azure’s transparent data encryption, and uploaded files are encrypted at rest by Azure Storage. Both use AES-256 and are on by default for every Azure database and storage account.
Field-level encryption on top. In production, the most sensitive fields are encrypted a second time, inside the application, separately for each category of data, before they reach the database. The categories covered are:
- contact details — email addresses and phone numbers;
- identity documents — passport and visa numbers, and nationality;
- addresses and employment details, including current employer and salary range;
- health and accommodation notes, and emergency-contact details;
- invitation tokens, and the tokens for any cloud account a user connects;
- the content of emails captured into a case, and case, task and person notes;
- the details read out of documents by the AI, and conversations with the assistant.
The application refuses to start in production if this encryption is not switched on.
Backups. The database is backed up automatically and backups are retained for 7 days. We use them to restore the service after a failure, not to bring deleted records back into normal use.
Logging and monitoring
Section titled “Logging and monitoring”Audit log. Every administrative action and every change to a case, a person or a document is recorded: who did it, what changed, and when. Actions taken by the AI assistant on a user’s behalf are recorded the same way. Kept for 7 years.
Data-access log. Reads of personal and sensitive records — cases, documents and their content, transferee profiles, users, employers, extracted document details, signatures, and the data-export and erasure operations — are logged separately from changes. Kept for 7 years.
Sign-in records. Successful and failed sign-ins, password and authenticator changes, and administrative sign-in events are copied from the sign-in service into PILLAR’s own audit store. Kept for 2 years.
Personal data is masked in application logs. Names, email addresses, phone numbers and other personal values are masked before they are written to our structured application logs, so they do not appear there in plain text.
Automatic clean-up. Short-lived data is deleted on a schedule: in-app notifications and records of sent emails after 90 days, conversations with the assistant after 90 days, unfiled inbound mail after at most 90 days, and details read out of documents after 30 days by default. The Privacy Policy has the full table.
Inbound email capture: the safety check
Section titled “Inbound email capture: the safety check”A customer can let PILLAR read one shared case mailbox so replies are filed to the right case. The mailbox limit is set on the customer’s side, in Microsoft 365, using Microsoft’s feature for restricting an application to named mailboxes. Because that limit lives outside PILLAR, PILLAR checks it itself before every capture run: it inspects what its access token actually grants, and if the token carries any organisation-wide permission — which would mean PILLAR could read every mailbox in the customer’s directory — capture halts, the customer’s administrator is told that capture has paused and that nothing on their side needs changing, and our team is alerted to fix it. Capture does not run in that state, and a token PILLAR cannot read is treated the same way.
AI safeguards
Section titled “AI safeguards”- The assistant runs on OpenAI models hosted by Microsoft in Microsoft Foundry, inside our own Azure subscription. Microsoft states that prompts and responses are processed within its EU Data Boundary, are not used to train models, and are not available to OpenAI or other customers.
- Document reading sends the file name and the user’s description to an EU-resident OpenAI model to work out the document type, then sends the document to Azure AI Document Intelligence in our own region; if that service cannot read it, PILLAR falls back to an EU-resident OpenAI model in Microsoft Foundry.
- In production, PILLAR refuses, in code, to send data to any AI model that is not marked as EU-data-resident. If no such model is available, the request fails and the user is told.
- Every change the assistant proposes is shown to the user and waits for approval. Nothing is written on the assistant’s own initiative.
- Details read out of a document are shown as suggestions until a person saves them.
- Conversations are deleted after 90 days; extracted details after 30 days by default.
Sub-processors and their certifications
Section titled “Sub-processors and their certifications”These are the companies that process personal data for us, and what each one states it is certified or audited for. The statements are each provider’s own; we link to the page we read them from. We will tell customers before adding a sub-processor.
| Provider | What it does for PILLAR | Where | Certifications the provider states it holds |
|---|---|---|---|
| Microsoft Azure (hosting, SQL database, storage, Key Vault, Container Apps, cache, Azure AI Document Intelligence, Microsoft Foundry) | Runs the platform and the AI features | Sweden Central; AI within the EU Data Boundary | ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, ISO/IEC 27701, SOC 1, SOC 2 Type 2, SOC 3, EU Cloud Code of Conduct — Azure compliance offerings, ISO/IEC 27001, SOC 2 Type 2 |
| Twilio SendGrid | Delivers the emails PILLAR sends | United States | SOC 2 Type 2 — Twilio security (Twilio notes that not every credential applies to every product, and does not list ISO 27001 for SendGrid) |
| BoldSign (Syncfusion) | Electronic signatures | Hosted on Microsoft Azure and Google Cloud, in US, EU, Canada and Australia data centres | SOC 2 Type 2 — BoldSign security |
Keycloak, our sign-in software, is open source and runs inside our own Azure environment; it is not a separate provider.
What PILLAR does not have yet
Section titled “What PILLAR does not have yet”- No certification of our own. PILLAR Relocation ApS is not certified to ISO 27001 or SOC 2 and has not been through an external audit. Our providers’ certifications cover their part of the system — the data centres and the cloud services — not our application. We design and run the platform with those principles in mind, and we will pursue certification when our customers need it.
- No published penetration-test report. We have not yet commissioned an independent penetration test.
- No uptime guarantee on this page. Availability commitments belong in the agreement with each customer.
Reporting a security concern
Section titled “Reporting a security concern”If you believe you have found a security problem in PILLAR, write to support@pillarrelocation.com. We will acknowledge it and tell you what we find.
PILLAR