Altivane Data Processing and Security Statement

1. About this statement

The App runs on the Customer's own computer, reads and changes the Customer's Tenants in Microsoft's cloud, and keeps what it reads on that computer. It sends us nothing from the Tenants. We hold only what we need to license, update and support the App, and the Customer's contacts.

1.1 This statement is made by [Legal entity] (ABN [ABN]) of [Address] (we, us) to each customer that holds a Licence (Customer).

1.2 It has 2 parts:

1. a data processing addendum (clauses 2 to 14), which forms part of the Altivane end user licence agreement between us and the Customer or, for the Licences a managed service provider holds for its own staff, of the Altivane MSP partner and reseller agreement (either one, the Licence Agreement); and
2. a plain security overview (clause 15), which answers the questions most security questionnaires ask. It is a summary for information only: it doesn't bind either party, and clauses 2 to 14 prevail over it.

1.3 It covers the App and the Services, the Portals included. It does not cover Microsoft's services or the Customer's AI Provider. Our website, its accounts and our forms service are not covered either: the Altivane website and account terms of use and our privacy policy at [Website address]/privacy cover them.

1.4 If this statement and the Licence Agreement disagree:

1. on Held Data, Local Data, Personal Information and security, and on the refunds in clauses 6.3 and 14.2, this statement applies; and
2. on anything else, including the limits on liability (clause 13), notices and governing law, the Licence Agreement applies.

If this statement and the Altivane support and maintenance policy disagree about data or security, this statement applies.

1.5 Nothing in this statement excludes, restricts or modifies a right or remedy the Customer has under the Australian Consumer Law that the law says can't be excluded, restricted or modified. Such a right is subject only to the limit in clause 13.2, where that limit applies.

1.6 This statement describes version 1.0.0 of the App, and the Services as they stand on the date at the top of this statement. Before a later version handles data in a new way, such as syncing settings between computers through a service of ours, we will update this statement under clause 14.2.

2. Definitions and interpretation

A term in bold below has this meaning wherever it starts with a capital letter.

2.1 In this statement:

2.2 Headings, and the summary in italics under each heading, are for convenience only. They don't form part of this statement or change its meaning. "Including" and similar words do not limit what comes before them.

2.3 A reference to a law includes any law that amends or replaces it. A reference to a clause is to a clause of this statement, unless it names another document.

2.4 A term the Licence Agreement defines, such as Fees, Licence term, Seat and Activation, has the same meaning here, unless clause 2.1 defines it.

3. Roles and scope

The App sends us no Tenant Data. We hold only Licensing Data, Update Data and Contact Data, and any Support Data the Customer chooses to send us.

3.1 Tenant Data. The App runs on the Customer Computer and connects from there to the Customer's Tenants in Microsoft's cloud, where it reads and makes changes. What the App keeps of Tenant Data, it keeps on the Customer Computer (clause 4). The App never sends Tenant Data to us, and we have no service that receives, stores or can read it. Tenant Data leaves the Customer Computer only for Microsoft, for the AI Provider if the Customer turns AI summaries on (clause 7), and for wherever the Customer itself sends it, such as a support bundle it sends us (clause 3.6).

3.2 The Customer's role. The Customer decides which Tenants to connect, what access to grant, and what the App reads, changes and keeps. The Customer is responsible for Tenant Data under the Privacy Act and under its agreements with its own clients and with Microsoft.

3.3 Our role. We handle Held Data only to:

1. activate, renew, deactivate and check Licences;
2. tell the App about updates and supply them;
3. give the support the Customer asks for;
4. send the Customer notices about its Licence and this statement, and bill for the Licence;
5. keep the Services secure and explain refusals; and
6. meet our legal obligations.

3.4 We do not sell Held Data, use it for advertising, or use it to train AI models.

3.5 We handle Personal Information in Held Data in line with the APPs, whether or not the Privacy Act requires it of us.

3.6 If we receive Tenant Data, such as in a support bundle, we treat it as Support Data under this statement.

4. Data on the Customer Computer

The App keeps what it reads and makes on the Customer Computer, in the places below, and the Customer controls where it lives, who can read it and when it is deleted. Clause 4.5 lists everything the App connects to.

4.1 The App keeps this Local Data on the Customer Computer:

4.2 No Tenant passwords. The App never holds a Tenant password. With certificate sign-in it signs in as its own app registration. With interactive sign-in, an administrator signs in through the browser with their own account.

4.3 No licence key. The App does not store the licence key. It stores the signed lease, which shows only the key's last 4 characters. The key is never accepted as a command line argument, where other programs could see it.

4.4 New passwords and passes. These are shown once, on screen, to the person who ran the change: a password the App makes with Reset password, for a new user on the Users page or in a Blueprint, and a Temporary Access Pass that Microsoft issues through Issue a Temporary Access Pass. The App doesn't keep them, and doesn't write them to the change log, the Output pane or the diagnostic log. On the Users page, a password copied from that window stays out of the clipboard history, and is cleared from the clipboard when the window closes.

4.5 What the App connects to. The App connects only to:

1. Microsoft's sign-in and public APIs for the Tenant: Exchange Online, Entra ID, Intune, SharePoint, Teams, Defender and Azure;
2. the Licensing Service, to activate, renew and deactivate the Licence;
3. the Update Service, and the HTTPS address it gives for an update's download, only when a person selects Help > Check for updates; and
4. the AI Provider, only to write AI summaries, if the Customer turns them on, or, when a person selects Build, a Blueprint (clause 7).

4.6 Support bundles. A support bundle is a .zip file the App saves on the Customer Computer. The App sends nothing. It leaves out the settings file, the licence key, the sign-in cache, kept data, AI keys, change logs and documents. Its logs can name Tenants, people and devices, so the Customer checks it before sharing it.

5. Data the Services hold

The Licensing Service holds each Licence, its activations, who it is licensed to and an audit history. The Update Service receives the App's product, channel, processor type, version and build, and the IP address the request comes from. We also keep the Customer's contacts. None of them holds Tenant Data.

5.1 Licensing Data. The Licensing Service holds:

5.2 The licence key is never stored. The Licensing Service keeps only a keyed hash of it, for lookup, and its last 4 characters as a hint. We see a new key once, when we make it.

5.3 Computer and user IDs are hashed. The App makes the machine hash on the Customer Computer, from the product ID, the Windows machine ID and the Windows user's ID. The raw IDs are never sent. The User-Agent names the App and its version.

5.4 When the App contacts it. The App contacts the Licensing Service to activate, to renew in the background while the computer is online, and to deactivate. A lease lasts 7 days, so the App keeps working that long if the Licensing Service can't be reached.

5.5 No Tenant Data. Nothing about a Tenant is sent to the Licensing Service.

5.6 Update Data. When a person selects Help > Check for updates, the App sends the Update Service the product, channel, processor type, version and build. The request also gives the Update Service the IP address it comes from, which it uses to limit how often checks can be made. Downloading an update gives that IP address to the address that serves the download. The App sends nothing else. Its service logs may hold that IP address, and it keeps them for 30 days. It also keeps a daily count of checks for each version, which identifies no one.

5.7 Updates only when asked. The App never checks for updates on its own. It downloads an update only after the person selects Update, and starts the installer only after they select Install.

5.8 Support Data. Support Data is only what the Customer chooses to send us, by email to [Support email address]. We use it only to give that support, to keep the Services secure and to meet our legal obligations (clause 3.3).

5.9 Contact Data. We keep the names, email addresses and phone numbers the Customer gives us for its Licence, notices, security matters and billing, in our email and accounting systems. We use them only for the purposes in clause 3.3. The Licensing Service holds no email address: a Licence holds only the customer's and company's names.

5.10 Confidentiality. We keep Held Data confidential. Only our people who need it for a purpose in clause 3.3 can see it, and they must keep it confidential too.

6. Where the Services run, and Sub-processors

Both Services run on Microsoft Azure in the Australia East region, and Microsoft is our only Sub-processor for them. Clause 6.1 says where Support Data and Contact Data are held.

6.1 Our Sub-processors are:

6.2 Our website and forms service also run on Microsoft Azure in Australia East. Our privacy policy covers them.

6.3 We will tell the Customer at least 30 days before we add or replace a Sub-processor. If the Customer reasonably objects, it may end the Licence Agreement by notice and receive a pro rata refund of the Fees it prepaid for the rest of the Licence term.

6.4 We will choose Sub-processors whose terms protect the data at least as well as this statement requires. If a Sub-processor's standard terms fall short, we will close the gap with measures of our own where we can, and otherwise tell the Customer what falls short, so it can object as clause 6.3 allows.

6.5 We store Held Data in Australia, except where clause 6.1 names another country for Support Data, Support Records or Contact Data. Microsoft may reach data from outside Australia to run and support Azure, under its own terms. Apart from that, we do not disclose Held Data to anyone outside Australia.

6.6 Not our Sub-processors. Microsoft, as the provider of the Customer's Tenants, and the Customer's AI Provider each act for the Customer under the Customer's own agreement with them. They are not our Sub-processors.

6.7 Requests from government or police. If a government agency, a court or the police asks us for Held Data, we will give only what the law requires. We will tell the Customer first, unless the law stops us.

6.8 If our business is sold. If we sell or transfer the business that supplies the App, Held Data may pass to the buyer, which must keep to this statement. We will tell the Customer before it passes, and the Customer may then end the Licence Agreement as clause 6.3 allows.

7. AI summaries and Build with AI through the Customer's own AI Provider

AI summaries are off until the Customer adds its own AI Provider and turns them on. The App then sends summary figures from the Customer Computer straight to that AI Provider. Build with AI sends it only the description a person types and a description of the Blueprint format, when they select Build, and nothing from a Tenant. Nothing passes through us.

7.1 When a summary is written. Only when Settings has an AI Provider with its API key, Write AI summaries in documents is on, and the Tenant has Write AI summaries for this tenant on. Importing settings never turns AI summaries on.

7.2 What is sent. The headings of the scorecard reports, status counts and summary figures, with the writing profile's instructions. Names and detail tables are never sent. Names, addresses and IDs in the figures are replaced before anything is sent. A block's What to bring out text is sent too, with the client's and the Tenant's names, the Tenant ID and its domains replaced. Anything else a person types there is sent as typed, so it shouldn't name people.

7.3 A record of each request. Exactly what was sent and what came back is saved beside each document, as a .txt file. See what would be sent shows a block's request using the sample document, and sends nothing.

7.4 The API key. The key is encrypted for the Windows user and is not written to the settings file. Test checks the address and key and sends nothing about a Tenant.

7.5 The Customer's choice. The AI Provider can be Anthropic, or any service that uses the OpenAI API, such as OpenAI, Azure OpenAI or a model on the Customer's own computer. The Customer's agreement with it governs what it keeps, where and for how long. We are not responsible for what the AI Provider does with the data.

7.6 Before turning AI summaries on, the Customer should check its AI Provider's terms, where it processes data, and whether the Customer's own clients agree.

7.7 Build with AI. On the Blueprints page, New > Build with AI opens a window where a person describes what a Tenant should have, then selects Build. It shows only when Settings has an AI Provider with its API key and a model chosen under the document summaries. It doesn't need Write AI summaries in documents on.

1. What is sent. Only when the person selects Build: the description they typed, and a description of the Blueprint format (its sections, fields and rules, with 1 sample Blueprint). Nothing from a Tenant is sent: no names, IDs or Tenant Data. It goes from the Customer Computer straight to the AI Provider, under the Customer's own API key and terms. Nothing passes through us.
2. Corrections. If the App finds problems in the answer, it sends the answer back to the same AI Provider once, with the problems, to be corrected.
3. The answer. The App saves it as a new Blueprint on the Customer Computer and opens it. Nothing is previewed or applied for the person.
4. The diagnostic log. It records only that a Blueprint was built, the service, the model and the description's length in characters, never the description.
5. The Customer's review. A Blueprint the AI Provider writes can be wrong. The Customer reviews and previews it before applying it, and is responsible for what it applies to a Tenant.

8. Security measures

We protect the App and the Services with the measures below.

8.1 In the App:

1. Sign-in by certificate. With certificate sign-in, the App signs in to a Tenant as its own app registration, with a certificate in the Windows user's personal store. A certificate the App creates is valid for 2 years, and its private key can't be exported.
2. Access the Customer chooses. The Customer picks the access (Reports, Helpdesk, Manage, Everything or Custom) and sees every permission and role before an administrator grants consent. The App only ever adds access; the Customer removes it in the Microsoft Entra admin centre.
3. Azure read only unless granted more. In Azure, the App gets the Reader role only on the subscriptions the Customer selects. A change in Azure needs a role an administrator assigns there.
4. Changes shown first, then recorded. A change made from a page runs from a window that names the change, its targets and the Tenant, and nothing is sent until the person selects Run. For a change that blocks or removes something, such as Block sign-in or Wipe a device, Enter doesn't run it. A Blueprint is previewed and confirmed once before it applies. A workflow can be test run first. Run from the window, a workflow asks before it makes changes when Ask before a workflow makes a change is on in Settings, and always when a step blocks or removes something. Run from Task Scheduler or the command line with --apply, it asks nothing. Each change sent is recorded in the Tenant's change log, unless the Customer turns the log off.
5. Never sent twice. When the App can't tell whether a change went through, it never sends it again. The change shows as failed, and the record stands.
6. Encryption on the computer. Kept data, the sign-in cache, the licence and AI keys are encrypted with Windows data protection, for the Windows user.
7. Encryption in transit. The App reaches Microsoft and the Services over HTTPS. It reaches the AI Provider at the address the Customer enters.
8. Signed and checked. The App's files are signed with our code-signing certificate. At each start, the program and its engine check each other's signature against our pinned certificate, and refuse to run if either has been changed.
9. Protected code. The App's engine is compiled to native code and obfuscated, with its strings encrypted, so it is hard to copy. This protects our intellectual property. It hides nothing from the person running the App: the Microsoft APIs it calls are public, and its logs and reports show what it did.
10. Updates checked. Before an update's installer starts, the App verifies the release and checks the download's size and SHA-256 hash. It downloads an update only from an HTTPS address that the signed release names.

8.2 In the Services:

1. HTTPS only. The Licensing Service works over HTTPS only, and redirects HTTP to HTTPS. The App reaches both Services, and downloads updates, over HTTPS only.
2. Signed requests. Each request from the App is signed with a key the App makes on the Customer Computer and keeps, non-exportable, in the Windows user's key store.
3. Signed leases. Each lease is signed inside Azure Key Vault. The signing key never leaves Key Vault.
4. No secrets in the App. The App holds nothing that can create or sign a Licence, and nothing that can reach our database or Azure.
5. No database passwords. The Licensing Service reaches its database and Key Vault with its own managed identities. The database accepts Microsoft Entra sign-in only.
6. Least privilege. Each service identity has only the roles it needs. The management portal can only read a summary of each Licence: it can't read key hashes or notes, or write anything.
7. Admin access. Only people we assign can sign in to the Portals, through Microsoft Entra ID with multi-factor authentication. The licensing portal checks their role on every page.
8. Checked input. The Licensing Service checks every input, refuses requests over 16 KB, and limits how often each IP address and installation can call it. The Update Service limits how often each IP address can check for updates.
9. Deployments. The Services change only when we start a deployment by hand, from our main code. The Licensing Service deploys only code that has passed its tests and dependency and secret scanning, and its deployment signs in to Azure with no stored secret.
10. Patching. We deploy .NET's security fixes to the Services within 14 days of Microsoft's monthly security release.
11. Encryption at rest. The Licensing Service's database and its backups are encrypted at rest with Azure SQL Database's transparent data encryption.
12. Backups. Azure SQL Database backs up the Licensing Service's database automatically, so it can be restored to an earlier point in time. The backups stay in Australia.

8.3 Independent testing. No independent party has yet tested the App or the Services, and we hold no security certification. We will update this clause when that changes.

8.4 Keeping them. We will keep the measures in this clause 8 at least this strong while the Licence Agreement runs.

8.5 Reporting a security flaw. Anyone who finds a security flaw in the App or the Services can report it to [Security contact email]. We will acknowledge it and say what we will do about it.

9. Logs and retention

On the Customer Computer, the App deletes its diagnostic log after 14 days and keeps page data for 7 days by default; the Customer deletes everything else. We keep Held Data for the periods below.

9.1 Each kind of data is kept for:

9.2 The change log is the Customer's record. For each change, it records who was signed in and which Windows account and computer made it. The App never sends it to us.

9.3 What our logs leave out. The Licensing Service's logs never hold private keys, secrets, tokens, request bodies or full licence keys. A key appears only masked, as its last 4 characters. They do hold IP addresses and installation IDs, such as when they record repeated failures from 1 IP address or installation.

9.4 Audit history is kept apart. The audit history is stored in the Licensing Service's database, apart from its service logs.

9.5 Deleting what we no longer need. When we no longer need Personal Information in Held Data, we take reasonable steps to destroy or de-identify it, in line with APP 11.2. The Licensing Service can't yet do this itself, so we do it by hand: every 3 months, we delete or de-identify the Held Data whose period in clause 9.1 has passed.

10. Data breaches

We tell the Customer promptly about a Security Incident affecting its data. A breach of Local Data happens in the Customer's own systems, so the Customer assesses it, with our help.

10.1 Our notice. We will tell the Customer without undue delay, and no later than 72 hours after becoming aware of a Security Incident affecting its data. We will send the notice to the security contact in its Contact Data, or if there is none, to its notices contact. As far as we know at the time, it will say:

1. what happened, and when;
2. what data and which Licences are affected;
3. what we have done, and will do, to contain it; and
4. who to contact.

We will update the Customer as we learn more.

10.2 The Notifiable Data Breaches scheme. If we suspect an Eligible Data Breach, we will assess it within 30 days, in line with Part IIIC of the Privacy Act, whether or not the Privacy Act requires it of us. If it is one, we will notify the Office of the Australian Information Commissioner (OAIC) and the people at risk as soon as practicable. Where we can, we will tell the Customer before we notify.

10.3 A breach affecting both of us. If a Security Incident involves Personal Information the Customer is also responsible for, such as Tenant Data in Support Data, we will work with the Customer so that 1 assessment and 1 notice are made, as the Privacy Act allows.

10.4 Breaches of Local Data. Local Data is kept on the Customer Computer, so a breach of it happens in the Customer's own systems. The Customer assesses and notifies it under its own obligations. We will give reasonable help, such as explaining what the App stores and where.

10.5 The Customer's notice to us. The Customer will tell us promptly at [Security contact email] if it suspects a licence key, a Customer Computer or a Windows account running the App is compromised. We can then revoke the affected activations.

10.6 Telling the Customer about a Security Incident is not an admission of fault.

11. Access, correction and deletion

The Customer deletes Local Data itself, on its own computers, at any time. We correct Held Data on request, and delete or de-identify it by hand, except what we must keep.

11.1 To delete Local Data from a Customer Computer, in this order:

1. Select Help > Licence > Deactivate this computer, which frees the seat. Uninstalling the App doesn't deactivate it.
2. Select Admin > Settings > Data and refresh > Clear kept data.
3. Delete the output folder, which holds each Tenant's reports, documents, AI summary records, workflow files, run logs and change log.
4. Delete the Blueprints, workflows and templates folders, if they are kept outside the output folder.
5. Delete the settings file, which Help > About shows, and, for each Windows user that runs the App, the %LOCALAPPDATA%\Altivane folder, which holds the sign-in cache, licence, AI keys, kept data and diagnostic log.
6. Delete the certificates the App created from the Windows user's personal certificate store, and any copies the Customer put in another Windows user's store or the computer's store for scheduled runs.
7. Delete the App's installation key from the key store of each Windows user that activated it. Its name starts with Altivane-installation-, and deactivating doesn't remove it.
8. Delete the Task Scheduler tasks that run the App.
9. Uninstall the App.

11.2 To remove the App from a Tenant. Removing a Tenant from the App doesn't change the Tenant or its app registration. To take the App's access away, delete its app registration and enterprise application in the Microsoft Entra admin centre, and remove every Azure role assigned to it, Reader and any other, on any subscription or resource.

11.3 Held Data. The Customer, or any person whose Personal Information is in Held Data, can ask to see or correct it by writing to [Privacy contact email]. The Customer can also ask us to delete its Licensing Data, Contact Data, Support Data or Support Records. We will answer within 30 days. We make corrections and deletions by hand, since the Licensing Service can't yet delete records itself. Deleting Licensing Data ends the Licence's activations. We may keep the audit history for the period in clause 9.1, for security and legal reasons, and anything the law requires us to keep.

11.4 Support Data. We delete Support Data 30 days after the support request is closed, sooner if the Customer asks, or later if it asks us to keep it longer. We keep Support Records for 2 years after the support request closes.

11.5 When the Licence Agreement ends. We deactivate the Licence's activations. Once the periods in clause 9.1 have passed, we delete or de-identify its Licensing Data and Contact Data by hand, at the next review under clause 9.5, except anything the law requires us to keep.

12. The Customer's responsibilities

The Customer is responsible for the computers, Windows accounts and Tenants the App runs with, since Local Data lives there.

12.1 The Customer will:

1. take reasonable steps to secure each Customer Computer and each Windows account that runs the App, such as disk encryption and current updates;
2. have the authority of each Tenant's owner to connect the Tenant, and to read and change it with the App;
3. grant each Tenant the least access it needs, and remove access it no longer needs;
4. control who can read the output folder, the change logs and any support bundle;
5. check a support bundle before sending it, since its logs can name Tenants, people and devices;
6. decide whether to use AI summaries, and check its AI Provider's terms first (clause 7.6);
7. give us a notices contact and a security contact, and keep them up to date; and
8. keep its licence key private.

12.2 The Customer's obligations to its own clients, under the Privacy Act and its contracts, stay with the Customer. Nothing in this statement moves them to us.

13. Australian Consumer Law and liability

The Customer keeps the rights the Australian Consumer Law gives it. Beyond them, the Licence Agreement's limits on liability apply, with 1 cap for both documents.

13.1 Consumer guarantees. Nothing in this statement excludes, restricts or modifies a right or remedy the Customer has under the Australian Consumer Law that the law says can't be excluded, restricted or modified, including the consumer guarantees that come with the App and the Services. The Licence Agreement says what they are and what the Customer is entitled to.

13.2 Limit for business supplies. Where the App or the Services are not of a kind ordinarily acquired for personal, domestic or household use, our liability for failing to meet a consumer guarantee is limited, at our choice, as section 64A of the Australian Consumer Law allows, to:

1. for the Services, supplying them again or paying for them to be supplied again; and
2. for the App, replacing or repairing it, or paying for that, except the guarantees of title, undisturbed possession and undisclosed securities (sections 51 to 53 of the Australian Consumer Law), which this limit doesn't cover.

This limit doesn't apply where it would not be fair or reasonable for us to rely on it.

13.3 Limits. Subject to clauses 13.1 and 13.2, the Licence Agreement's limits on liability apply to liability under or in connection with this statement, as if it were part of that agreement: its cap, the losses it excludes and the exceptions to both. There is 1 cap for both documents: liability under this statement counts towards the Licence Agreement's cap and is not added to it.

13.4 Shared causes. Each party's liability is reduced to the extent the other party, or something it is responsible for, caused or contributed to the loss. For the Customer, that includes its computers, Windows accounts and Tenants, its AI Provider, and its own errors in choosing, setting up or running a change, such as the wrong targets or values. It doesn't include a change that went wrong through a defect in the App.

13.5 Microsoft's services. We are not responsible for Microsoft's services, which the Customer uses under its own agreement with Microsoft.

14. General

This statement lasts as long as we hold any of the Customer's data, is governed by the same law as the Licence Agreement, and changes only on notice.

14.1 Term. This statement applies while the Customer holds a Licence, and after that for as long as we hold any of the Customer's Held Data.

14.2 Changes. We may update this statement by giving the Customer at least 30 days' notice. A change that reduces the protection of Held Data or Local Data needs the Customer's written agreement. If the Customer, acting reasonably, says a change reduces that protection, it is treated as one. If the Customer objects to any other change before it takes effect, it may end the Licence Agreement by notice and receive a pro rata refund, as in clause 6.3.

14.3 Questions and help. We will answer the Customer's reasonable security and privacy questions, and give reasonable help with its privacy obligations, at no charge up to 10 hours a year. Beyond that, we quote first and charge only if the Customer agrees, at our hourly rate for work outside support (clause 8.2 of the Altivane support and maintenance policy). Help with a Security Incident, or with a breach of Local Data that we caused, is always at no charge.

14.4 Notices. Notices under this statement are given as the Licence Agreement says. We also send a notice under clause 10 to the security contact in the Customer's Contact Data.

14.5 Severance. If part of this statement is unenforceable, it is read down or severed, and the rest stays in force.

14.6 Governing law. The law that governs the Licence Agreement governs this statement, and the courts that hear disputes under that agreement hear disputes under this one.

14.7 Insurance. We hold professional indemnity insurance and cyber insurance, each of at least [Insurance amount] for each claim.

15. Security overview: questionnaire answers

Short answers to the questions a security questionnaire usually asks. This clause is a summary for information only: clauses 2 to 14 prevail over it (clause 1.2), and the clause named in each row holds the detail.