Privacy Policy.

1. Who we are

Armada Solutions LLC (“Armada”, “we”) is a Kansas limited liability company based in Wichita, Kansas. We build a white-label Microsoft 365 security-posture platform sold to managed service providers (MSPs).

• Website: https://armada-solutions.com
• Privacy contact: hello@armada-solutions.com

We are two people. There are no employees. A founder reads every message sent to the address above.

2. The short version

We collect four fields from a website form: your name, your company name, your work email, and roughly how many client tenants you manage. That is the entire set.

We run no analytics, set no tracking cookies, and use no ad networks. You can verify this by viewing the page source. There is no tracking script to find.

When the platform scans a Microsoft 365 tenant, the raw telemetry is read into memory, evaluated, and discarded. It is never written to disk or to a database. We keep the result: a score, a per-control status, a timestamp, and a signed hash. We do not keep the evidence the result was computed from, because the storage layer has no table to put it in.

3. Two different roles, kept separate

This policy covers two distinct relationships. Read the one that applies to you.

The role labels in this table are drafting positions that need counsel’s confirmation. The factual descriptions of what we hold are accurate as of the date above.

Part A: Website and marketing contacts

4. What we collect

From the contact form (/contact.html), exactly four fields:

• Your name
• Your MSP or company name
• Your work email address
• Approximately how many client tenants you manage (optional, free text)

From email you send us. Whatever you choose to put in it.

That is the complete list. There is no hidden field, no enrichment step, no third-party data broker in the path.

5. What we do not collect

• No tracking cookies. Our site code sets no cookies of any kind and does not use localStorage or sessionStorage. (Cloudflare, our host, can set a strictly functional security cookie when certain protection features are enabled. We do not read it, and we do not use it to identify or track you.)
• No analytics. No Google Analytics, no tag manager, no Cloudflare Web Analytics, no self-hosted analytics. None is installed as of the date above.
• No advertising or retargeting pixels. No ad network receives anything from this site.
• No user accounts and no passwords. The website has no login. The platform uses machine authentication and Microsoft identity, not Armada-held passwords.
• No behavioral profiling, no automated decision-making about you, no sale of personal data. We have never sold personal data and have no mechanism to do so.
• No third-party requests at all. Fonts, styles, scripts, and the animation library are served from this domain. Reading this page discloses your IP address to our host and to nobody else. Until 2026-07-29 the two typefaces were loaded from Google Fonts, which disclosed every visitor’s IP address to Google; that dependency has been removed and the font files are now served from here. Open your browser’s network panel and confirm it.

If we ever add analytics, this section changes first and the change is dated (see §18).

6. Why we collect it, and what we do with it

We use the four form fields to answer you, to have a conversation about whether the product fits your business, and to keep a short record of who we have spoken to during pre-launch research. That is all.

We do not add you to a marketing automation platform. There is no drip sequence running against form submissions. If we ever start a mailing list, joining it will be a separate, explicit opt-in.

Our drafting position on legal basis (for anyone to whom UK/EU GDPR applies): legitimate interest in responding to a business enquiry you initiated, and steps taken at your request prior to entering a contract.

7. How long we keep things

These periods are proposed, not yet enforced by automation. Deletion today is a manual process performed by a founder. Automated retention enforcement is on the roadmap and is not in place.

Part B: The platform and client tenant data

8. How the platform reads a tenant

• We read Microsoft 365 signals through the Microsoft Graph API using read-only, least-privilege application permissions.
• Access runs through the delegated admin (GDAP) relationship the MSP already holds with its client. We do not create a new trust path.
• Nothing is installed in the client tenant. No agent, no forwarder, no scheduled task, no mailbox rule.
• The permissions are read-only. The platform can look. It cannot create, modify, delete, or administer anything in a client environment.
• The client can revoke access at any time, from their own Microsoft portal, without asking their MSP or asking us. Revocation ends our ability to read that tenant immediately.

9. The ephemeral model, stated plainly

For each scan:

1. Signals are read from Microsoft Graph into process memory.
2. They are evaluated against a versioned control catalog.
3. The buffer is released. The process ends.

Raw telemetry is never written to disk and never written to a database. This is not a policy we promise to follow. It is an absence in the architecture. The storage layer has exactly two physical tables:

• clients: enrollment records
• attestations: scan results

There is deliberately no table, no field, and no code path for raw scan telemetry. Adding one would require writing new code that does not exist today.

10. What is actually stored

In clients: an internal client identifier, the MSP’s tenant identifier, the client organisation’s display name as the MSP entered it, the client’s Microsoft tenant identifier, grant status, creation and grant timestamps, and the most recent score and tier. These are business identifiers, not the contents of anyone’s mailbox or directory.

In attestations, per scan: the client identifier, a timestamp, the catalog version, the numeric score, the tier, the per-control status (pass / partial / fail / not_verified), coverage figures, a hash of the control states, a hash chained to the previous attestation, and a cryptographic signature.

Not stored anywhere: user lists, mailbox contents, file contents, message contents, sign-in logs, policy bodies, device inventories, or any other raw Graph response.

Two honesty markers that ship in the data itself:

• Every attestation records whether the scan ran against live Graph data or mock fixture data. The field is never omitted, so a demo result cannot be mistaken for a real one.
• A control the platform could not verify is recorded as not_verified. It is never estimated, inferred, or defaulted. Scores are computed only over verified controls; if nothing is verifiable, the result is “insufficient verified data”, not a zero.

Current coverage: 4 of the 13 controls in the catalog are verifiable by live telemetry today. The other 9 render as not verified. Coverage expands integration by integration.

11. Data subject and client requests for platform data

The MSP is our customer and is the party we take instructions from. If you are an MSP’s client and want your tenant’s records removed:

1. Fastest path: revoke the application’s access in your own Microsoft portal. That stops all future reads immediately, without involving us.
2. Ask your MSP to request deletion, or write to hello@armada-solutions.com directly and we will coordinate with your MSP.

We will delete the enrollment record and the attestation chain for that tenant on request. Note that deleting attestations breaks the hash chain for that client. That is the intended trade-off, and we will say so rather than quietly refuse.

Because we never hold raw telemetry, most access requests have a short answer: the records we hold about a scanned tenant are the scores, statuses, timestamps, and hashes listed in §10, and we can export them in full.

12. Third parties in the chain

We use four external services. There are no others in the production path.

Each of these is a separate company with its own privacy terms. The full list, including what each one can access and the two we removed on 2026-07-29, is published at Sub-processors. We have not yet executed data processing agreements with them. That remains a pre-launch task, and it is listed with the other open items at Sub-processors §6.

13. International transfers

Cloudflare’s edge network is global by design; static pages are served from wherever the visitor is. FormSubmit and Microsoft Azure are US-headquartered providers. Our Azure deployment region has not been finalised, and we have not yet implemented a transfer mechanism (Standard Contractual Clauses or equivalent) for personal data leaving the EU/UK.

We are stating this rather than papering over it. If you are an EU or UK MSP evaluating us, treat this as an open item and ask us where it stands at the time you read this.

14. Security posture: what is true today

• Access to client tenants is read-only and least-privilege, and it is revocable by the client at any time from their own portal.
• Attestations are signed with ECDSA P-256 and each record’s hash is chained to the previous one, so history cannot be quietly rewritten without breaking the chain.
• The API endpoints require machine authentication. There are no user accounts and no passwords anywhere in the system.
• Signing keys are currently a development keypair generated locally. Azure Key Vault-backed signing is designed and stubbed, but it is not in place yet. Anyone relying on the signature as third-party-verifiable evidence today should know this.
• We are not SOC 2 certified. No Type I and no Type II report exists. An independent audit is on the roadmap. We will not claim it before it is earned.
• We have not had an independent penetration test.

15. Children’s data

The platform is a business tool sold to managed service providers. It is not directed to children, and we do not knowingly collect personal data from anyone under 18 through the website. If you believe a child has submitted information through our contact form, write to hello@armada-solutions.com and we will delete it.

16. Regulatory posture, stated honestly

We have not completed a professional privacy assessment. We are therefore not claiming GDPR or CCPA compliance as a settled fact.

What we can say:

• We collect very little personal data, and what we collect is listed in full in §4.
• We do not sell or share personal data for cross-context behavioral advertising, so the CCPA/CPRA opt-out that would normally apply has nothing to operate on.
• The ephemeral architecture means the data-minimisation question that usually dominates a security-tooling privacy review largely answers itself.
• A formal assessment of GDPR and CCPA obligations, including whether either applies to us at our current scale, is pending and will be completed before general availability.

If a specific compliance answer matters to your procurement process, ask us and we will tell you exactly where it stands rather than sending a badge.

17. How to reach us about privacy

Email hello@armada-solutions.com with “Privacy” in the subject line. A founder reads it. We aim to respond within 5 business days and to complete deletion or access requests within 30 days.

Postal: Armada Solutions LLC, [TO BE COMPLETED], Wichita, Kansas, United States. (Full street address to be inserted before publication.)

18. Changes to this policy

When this policy changes, the “Last updated” date and version marker at the top change with it. Material changes (a new category of collected data, a new sub-processor, a new retention period) will be summarised in a short changelog at the bottom of the published page, and existing platform customers will be notified by email at least 30 days before the change takes effect.

We will not make a material change quietly and let the date line do the work.

Changelog

0.2-draft · 2026-07-29. Removed Google LLC as a recipient: the site’s two typefaces were being loaded from Google Fonts, which disclosed every visitor’s IP address to Google. The font files are now served from this domain. The animation library was moved off a public CDN for the same reason. Added a §5 entry recording that the site now makes no third-party requests at all. Published the sub-processor list and linked the open items from §12, replacing the note that no list had been published. No change to what we collect or how long we keep it.

0.1-draft · 2026-07-25. First published version.