Data Handling & Privacy

Overview

OrgGuard is a Salesforce-native managed package with a strict architectural commitment: your data stays in your Salesforce org. This page is the customer-facing reference for what OrgGuard does and does not transmit, by what mechanism, to whom, and under what consent model. It is the source-of-truth for procurement reviews, AppExchange security questionnaires, and CISO due diligence.

The 30-second summary

Question	Pro 1.0 answer
Does OrgGuard make outbound HTTP callouts from my org?	No outbound callouts. OrgGuard uses Salesforce’s Tooling API and Metadata API — self-callouts to your own org’s endpoints — for asset discovery. Zero HTTP calls leave your org domain. Enforced architecturally and by CI gate.
Does OrgGuard send my asset data to Aetrum or any third party?	No. All asset data, configuration, findings, and audit history stay in your org.
Does OrgGuard collect usage telemetry or crash reports?	No. Not collected. Not built in Pro 1.0. Future telemetry will be opt-in, off by default.
Does OrgGuard send anything to an AI / LLM service?	No. AI augmentation is a future Max-tier-only opt-in feature. Not available on Free / Pro / Pro+ even with explicit opt-in.
Is any data transmitted outside my org?	Yes — license metadata only. Salesforce’s License Management App synchronizes a fixed, documented set of license fields (org ID, package version, license tier, install date). The list is exhaustive and enumerated below.
Where is the contract for “no callouts”?	BRD §15 Architecture Principle 1, BRD §16 Data Boundary, and the NFR-22 CI parity gate. Any code change that would introduce a callout fails CI unless the BRD is updated in the same commit.

The three-column data boundary

This is the canonical model. Everything OrgGuard does with data falls into exactly one of three columns.

Column 1 — Stays in your org

Every byte in the left column lives only inside your Salesforce org. None of it leaves your org boundary. Aetrum cannot see, query, or retrieve any of it.

Data	Stored in
All discovered assets (certificates, Connected Apps, Named Credentials, External Credentials, Auth Providers, scheduled jobs)	`orgguard__TrackedAsset__c`
Certificate parsed content (Subject, Issuer, NotBefore, NotAfter, SerialNumber, Fingerprint, SAN)	`orgguard__TrackedAsset__c`
Dependency mappings between certificates and the integrations that depend on them	`orgguard__CertificateDependency__c`
Findings, alerts, notifications	`orgguard__Finding__c`, `orgguard__Notification__c`
Immutable audit history	`orgguard__CertificateAuditEvent__b`, `orgguard__ScheduledJobEvent__b` (Big Objects)
Scan run history	`orgguard__Scan_Run__c`
Diagnostic logs	`orgguard__OrgGuard_Log__c`
Policy configurations	`orgguard__Policy__c`
Setup wizard configuration	`orgguard__OrgGuard_Setup__c`
Internal platform events	`orgguard__OrgGuard_Error_Event__e`, `orgguard__OrgGuard_Log_Event__e`, `orgguard__OrgGuard_SJH_Poll__e`
User feedback (planned — not built in Pro 1.0)	`orgguard__OrgGuard_Feedback__c` (Pro 1.1)

These records are governed by your org’s standard sharing rules, FLS, and record-level security. OrgGuard adds no new access channel for them.

Column 2 — Platform-shared via LMA

The Salesforce License Management App (LMA) is a standard AppExchange platform feature that Salesforce — not Aetrum — operates. Salesforce maintains the LMA infrastructure as part of every managed-package install. When you install OrgGuard, Salesforce automatically synchronizes the following fields to Aetrum’s License Management Org so Aetrum can issue, track, and renew your license:

LMA-Synchronized Field	What it is
Org ID	The 15-character Salesforce org identifier (e.g. `00Dxx0000004C92`)
Org name	The display name set on your org
Package version	Which OrgGuard package version is currently installed
License tier	Free / Pro / Pro+ / Max
Active user count	Per Salesforce LMA standard metric
Install date	When OrgGuard was first installed in your org
Uninstall events	Timestamp if OrgGuard is ever uninstalled
License expiration date	Where applicable to your license terms

This is the complete LMA list. No asset data, no certificate content, no findings, no user activity, no field content, and no other org content is transmitted via LMA. The fields above are the standard set Salesforce synchronizes for every AppExchange managed package that uses LMA — they are not OrgGuard-specific surveillance.

Column 3 — Opt-in only

Empty in Pro 1.0. No feature in the right column exists or is enabled in OrgGuard Pro 1.0. The column is reserved for future opt-in features:

Future opt-in feature	Availability	Default	What would be sent
Anonymous usage analytics	All tiers (Free, Pro, Pro+, Max)	Off	Feature usage counts, scan completion stats — anonymized
Crash reports	All tiers	Off	Stack trace, OrgGuard version, Salesforce API version — no customer data
AI augmentation (LLM-generated finding explanations)	Max tier only	Off	Finding metadata only (no certificate content, no user data) sent to a third-party LLM provider; not available on Free / Pro / Pro+ even with opt-in

When any of these features ship, they will follow NFR-21 consent UX requirements: per-feature explicit opt-in, never bundled with other consent, never auto-enabled on upgrade, with full disclosure of exactly what data is sent and where, before the toggle is flipped.

The four architecture principles (BRD §15)

These are the contract OrgGuard’s engineering team operates under. They are not aspirations — they are enforced by code, CI, and architecture review.

Principle 1 — Your data stays in your org

Zero Apex HTTP callouts to destinations outside your org in Pro 1.0 code paths. Outbound HTTP to Aetrum or any third party is architecturally prohibited. OrgGuard’s discovery engine uses Tooling API and Metadata API self-callouts (three classes: ToolingApiService, MetadataApiService, IdentityProviderCertDependencyProvider) — these call your own org’s /services/data/, /services/Soap/m/, and /.well-known/samlidp.xml endpoints to enumerate auth assets, and are distinct from outbound HTTP to Aetrum or third parties. The NFR-22 CI gate scans every pull request for new HttpRequest or callout: usage and fails the build if found unless the BRD §16 Data Boundary is updated in the same commit. The commitment is permanent for Pro 1.0; future opt-in features that require Apex HTTP callouts (telemetry, AI on Max) will follow Principle 4.

LMA platform sync is distinct from Apex callouts — it is a Salesforce-managed feature, enumerated exhaustively in Column 2 above.

Principle 2 — Read-only architecture

OrgGuard discovers and reports. It never modifies your org state. It does not change Connected App configurations, does not rotate certificates, does not delete scheduled jobs, does not edit Permission Sets, and does not touch any record outside its own namespaced objects. The only writes OrgGuard performs are to:

Its own orgguard__* custom objects (TrackedAsset, Finding, Policy, etc.)
Its own orgguard__* Big Objects (audit history)
Its own platform events (internal pub/sub only)

Even the Setup Wizard’s “auto-assign Admin permission set” step only writes a PermissionSetAssignment for you (the installer) — not for any other user.

Principle 3 — Salesforce-native delivery

OrgGuard is delivered as a managed package on the AppExchange. It is not a SaaS product wrapped in a Salesforce connector. There is no Aetrum-operated infrastructure, no Aetrum servers your data flows to, and no external dashboard. You install the package, the package runs entirely inside your org, and your data never leaves.

Any future feature that involves data transmission outside your org will ship:

Off by default — no automatic enablement, ever
Per-feature consent — opting into telemetry does not opt you into AI; opting into AI does not opt you into telemetry; both are independent toggles
Never bundled — consent cannot be hidden in a multi-feature checkbox
Full disclosure first — the UI will show exactly what data is sent, to whom, and over what mechanism before the toggle accepts a flip
Not auto-enabled on upgrade — when a new version ships with a new opt-in feature, your existing install stays opted-out

What we explicitly do not collect

These are not omissions — they are commitments.

No background telemetry. Pro 1.0 ships with no telemetry, no usage analytics, no crash reports. Even if the feature were built tomorrow, it would be off by default until you explicitly opt in.
No user activity tracking. OrgGuard does not collect who logs into your org, when, from where, or what they do. (Login activity monitoring is a Pro+ feature that, when shipped, executes entirely in-org with zero callouts — it surfaces native Salesforce login data to your admins; it does not transmit it to Aetrum.)
No customer asset data sent to AI services. Pro 1.0 does not use AI / LLM services. When Max-tier AI augmentation is eventually built, it will be opt-in, off by default, and even then only finding metadata (not certificate content, not user identifiers) is sent to the configured third-party LLM provider.
No data residency complications. Because no customer data leaves your org, OrgGuard adds no new data-residency obligations beyond what your Salesforce contract already governs.

FAQ

Where can I see the exhaustive list of what LMA shares?

In two places:

This page, Column 2 above (customer-facing summary)
BRD §16 Data Boundary in the OrgGuard requirements documentation (authoritative source, mirrored here)

The two lists are kept identical by the NFR-22 CI parity gate.

How do I verify OrgGuard makes no callouts in my org?

Three independent checks:

Setup → Remote Site Settings — OrgGuard registers zero remote sites that point outside your org domain. The package ships with no external remote-site entries.
Inspect the HTTP-using service classes directly. OrgGuard contains three Apex classes that use HttpRequest: ToolingApiService.cls, MetadataApiService.cls, and IdentityProviderCertDependencyProvider.cls. All three call URL.getOrgDomainUrl() — your own Salesforce org’s REST and SOAP endpoints — for Tooling API and Metadata API discovery. None of them target Aetrum or any third-party URL. You can verify by inspecting the setEndpoint(...) call in each class: the URL begins with your org’s own domain. These in-org self-callouts are architecturally permitted (they are how OrgGuard discovers your auth assets) and are distinct from outbound HTTP to Aetrum or third parties, which Pro 1.0 has zero of.
Event Monitoring (if your org has it) — filter to API callouts originating from the OrgGuard namespace. Any callouts you see should resolve to your own org domain, not to any external host.

What about future telemetry / AI features — when will they ship?

Telemetry (anonymous usage analytics, crash reports) is scheduled for the Pro+ Foundations milestone. AI augmentation is scheduled for the Max tier roadmap. Both are tracked in the OrgGuard backlog and will not ship without:

A new BRD §16 entry moving the feature from “future” to “current” in Column 3
A new opt-in toggle in OrgGuard’s Setup → Privacy page (to be built alongside the first opt-in feature)
Documentation updates here describing exactly what the feature transmits
A package version bump and an explicit admin action to opt in (no silent enablement)

You will see all four of these before any opt-in feature is functional in your org.

Can I disable LMA sync?

No — LMA sync is a Salesforce platform feature, not an OrgGuard feature. It is mandatory for any managed package installed via the AppExchange and provides Salesforce’s standard license management infrastructure. If your organization’s policy prohibits LMA-style license-metadata sharing, you cannot install any AppExchange managed package; this is not specific to OrgGuard.

Customers who need to document what LMA shares for their own compliance records can refer to Salesforce’s LMA documentation, which governs this behavior for all AppExchange ISVs. The specific fields listed in Column 2 above are standard across all AppExchange managed packages — they are Salesforce platform infrastructure, not OrgGuard-specific configuration.

What happens if I uninstall OrgGuard?

Salesforce’s LMA records the uninstall event timestamp (Column 2). All orgguard__* data in your org is deleted by the package uninstaller per Salesforce’s standard package-uninstall behavior. No copy of your data exists outside your org, so there is nothing to delete from Aetrum’s side.

Is this page the same as the marketing privacy policy?

No, they cover different audiences and different surfaces:

The marketing privacy policy (orgguard.com/privacy.html) covers Aetrum’s marketing site, email collection from contact forms, and cookie/analytics use on the marketing site itself.
This page (docs.orgguard.com) covers the OrgGuard product — what happens once you install the managed package into your Salesforce org.

The two are intentionally separate; the marketing privacy policy is about the act of visiting orgguard.com, while this page is about the act of running OrgGuard.

Permission Sets — who can see what inside your org
Post-Install Checklist — what runs automatically when you install
Scheduled Jobs — the in-org background jobs OrgGuard registers
Diagnostic Logging — the in-org log object that retains scan and policy execution traces
BRD §15 Architecture Principles and §16 Data Boundary (authoritative requirements source)