Hardenwell GRC

Privacy Policy

Last updated: October 19, 2026

This policy explains what information Hardenwell Cybersecurity Advisors LLC ("we", "us") collects through the Hardenwell GRC website and application at https://app.hardenwell.com (the "Service"), how we use it, and the choices you have.

Hardenwell GRC is owned and operated by Hardenwell Cybersecurity Advisors LLC. It is a platform for running security and compliance programs, used by IT and security consultants (our customers) and by the organizations they serve ("clients"). A customer's account on Hardenwell GRC is called a workspace; each client is kept separately inside it.

Who is responsible for your information

  • Account information (your name, email address and sign-in details): we decide how it is used, as described here.
  • Workspace content (everything a workspace stores about its clients — assessments, evidence, documents, risks, vendors, assets and connected-tool results): the workspace owner decides what goes into the Service and who can see it. We process this content on the workspace owner's behalf and only to provide the Service. If you are a client of a consultant who uses Hardenwell GRC, please contact that consultant first about your organization's information; we will help them respond.

Information we collect

Account and sign-in information

  • Name, email address and the workspace or firm name you give us.
  • Your password, stored only as a one-way hash. If you use two-step sign-in: passkey public keys (never your fingerprint, face or PIN), an encrypted authenticator-app secret, and hashed recovery codes.
  • If you sign in with Google or Microsoft: the provider's identifier for your account and your email address. We do not keep the provider's access tokens.
  • Security records: when you signed in, failed sign-in attempts (by email address and IP address, kept for 30 days to stop password guessing), and which method was used for the second step.

Workspace content

  • What people in a workspace enter or upload: client profiles, assessment answers and notes, evidence and files, policies and documents, risks, vendors, assets, plans, reports, comments and reviews.

  • An activity log of changes (who did what, and when) so the workspace can see its own history.

  • Policy acknowledgements: when a workspace asks someone at a client to read and acknowledge policies through an emailed link (no account needed), we store that person's email address and name, the name they type to sign, which policy and version they acknowledged, when, and the IP address it came from — so the client can show who agreed to which policy.

  • People at a client: a record per person who works for or with the client (name, title, email, department, other names they go by), built from the client's connected directory, names typed into the workspace, and people named in documents, interviews or the client's website. When AI is on, those sources are read to list the people named in them, with a short quote showing where. People the client's public website names with a title (staff, owners, managers) are added to the client's people list automatically, marked as found on the website and waiting for a scope decision; a workspace member can take them back or remove them. For documents and interviews, a workspace member decides whether each person is added. Patients are never added, and documents flagged as containing patient information are skipped.

  • Exclusion screening: when a workspace turns it on for a client, we compare the names of that client's people (and, if chosen, its vendors) with copies of public U.S. government exclusion lists — the HHS-OIG List of Excluded Individuals/Entities and SAM.gov exclusions — that the Service downloads. The comparison happens inside the Service; no names are sent to those agencies or to anyone else. We keep each check's result, the list entries that look like a match, and the decision a workspace member records. Background checks a workspace records (date, provider, result, note and any file it uploads) are stored like other workspace content.

  • Audits and outside auditors: when a workspace invites an auditor to one audit, we store the auditor's name, email address and firm, who invited them, when they last signed in and when their access ended. Auditors sign in with a personal link and a one-time code we email to them; we keep only hashes of the link, the code and their browser session. Their decisions, assessments and comments are kept in the audit's history under their name. Access ends when the audit is completed or the workspace removes it.

  • Trust centers: people who ask for documents on a trust center page a workspace publishes give their name, work email, company and reason, which we keep with the workspace's decision. If the page asks visitors to accept a confidentiality agreement, we keep the name, email address and company they enter, the agreement's version and when they accepted. Documents a visitor opens carry their name, email address and the date as a watermark. People who subscribe to a trust center's updates give an email address, which we keep with the dates they confirmed and unsubscribed; every update email has an unsubscribe link. We count page views, document views and requests per day without keeping visitors' IP addresses or device details. A workspace can erase a visitor, which removes their name and email address while keeping the record that a decision was made.

  • Customer questionnaires: security questionnaires a client receives from its customers (the file as uploaded, the questions and the answers people write and approve), and answers the client saves for reuse.

  • Scheduled reports: the names and email addresses of the people a workspace chooses to email a report to on a schedule. The report goes to them as a PDF attachment.

  • API and webhooks: a workspace administrator can create read-only API tokens (we store only a hash) and webhooks. Whoever holds a token can read what its scopes and clients allow, for example controls, risks, vendors and people's names (and, only with the contact scope, their email address, title and department); AI tools connected through the MCP server read the same way. Webhooks send short event notices (for example a check that failed, an evidence item expiring, a document approved or an access request from a company) to the address the administrator enters; we keep the notices we sent for 30 days.

  • Files attached in the assistant: files a member attaches to an AI conversation are stored like other uploads. Files that look like patient information are refused and not stored.

  • Ticketing tools: when a workspace connects its PSA or issue tracker (for example ConnectWise, HaloPSA, Autotask or Jira) and sends work to it, we send a title and description for each ticket — the problem, up to ten items involved (which can include people's names and email addresses, device names or account details), how to fix it, the client's name and a link back — plus priority, due date and any notes about a fix. We read back each ticket's status, assignee, due date, priority and title. The tool's credentials are stored encrypted.

A client's public website

When a workspace member asks, we read a few public pages of the client's website (for example the home, about, team, contact and privacy-notice pages) and look up the domain's public mail (MX) records. With AI on, the page text is sent to our AI provider to suggest profile details, risk answers and people, each with the quote it came from. We keep the list of pages read, what was detected and the suggestions; a workspace member accepts or rejects each profile detail and risk answer. People the pages name with a title are added to the client's people list (with the email address a page shows, when it's on the client's own domain); the others wait for a workspace member to decide.

Information from tools a workspace connects

A workspace may connect tools its client uses — for example Microsoft 365, Google Workspace, endpoint protection, backup, password manager, training, network or vulnerability tools. With the read access the client's administrator approves, we collect only the settings and summary information needed to answer assessment questions and keep evidence, for example: whether multi-factor authentication is enforced, how many administrators or inactive accounts exist, device encryption and compliance status, backup results and policy settings. Some checks list the accounts or devices that fail them so the gap can be fixed. From device management tools (for example Microsoft Intune, Jamf, Kandji or JumpCloud) we also read each managed device's name, operating system, owner, groups and enrolment date and its security settings — whether the screen locks and after how long, whether the firewall is on and whether antivirus is running — and we look through the device's list of installed apps only to recognise a password manager or antivirus product. We keep the product we recognise, never the list of apps. From HR and payroll systems (for example BambooHR, Gusto, Rippling, HiBob or Personio) we keep only each worker's name, work email, job title, department, location, manager, start and end dates, employment type and status, and use them to keep the client's people list current and to start offboarding when someone leaves; we never keep pay, tax identifiers, birth dates, home addresses, personal contact details or time off, and discard anything else an HR system sends before storing it. From vulnerability scanners, endpoint protection, remote-management and cloud security tools we keep each open security finding — its title, severity, CVE identifiers, the affected device or resource, the vulnerable software's name and version, and how to fix it — with when it was first seen, its due date and when it was fixed, so the history of fixes can be shown to auditors; workspace members can also import findings from a spreadsheet or add them by hand. To help clients manage vendor risk, Hardenwell GRC also checks public information about the vendors a client records — CISA's public catalog of known exploited vulnerabilities, and the public DNS records and HTTPS settings of each vendor's website domain — without sending any client data or personal information to do so. We do not read email or chat messages, and we do not read files except documents someone deliberately picks for import (see below).

From a connected directory (Microsoft 365, Google Workspace or Okta) we also read the names of the groups each person belongs to and the apps people sign in to or give access to with their work accounts, from the directory's app consent, sign-in and token records (for Google Workspace, each only if the client's administrator grants the extra read-only access; a workspace can switch app discovery off). For each app we keep its name and, where the directory reports them, how many people use it, when it was last used, what access it was granted and whether its publisher is verified — not who signed in. With a Microsoft 365 connection we also look up the public DNS records of the client's own email domains (SPF, DKIM and DMARC) to check that others can't easily send mail in their name; nothing is sent to anyone to do so.

From a connected Amazon Web Services account, Microsoft Azure subscription or Google Cloud project we also read each resource's name, region, tags or labels and security settings — for example whether a storage bucket or storage account blocks public access, is encrypted and keeps versions, whether a database is encrypted, reachable from the internet, audited and backed up, which ports a security group or network security group opens to the internet, whether disks are encrypted, whether encryption keys rotate and key vaults are protected from deletion, and whether configuration recording and activity logging are on. We also read the vulnerability findings Amazon Inspector and Microsoft Defender for Cloud report for the account's machines, container images and functions — the affected software and its versions, severity, CVE identifiers, whether a fix exists and the suggested fix — and which machines they scan, but not each machine's full list of software. Tags can include an owner's email address, which we use to show who answers for the resource; workspace members can also record an owner, notes and whether a resource holds health or personal information. From a Google Cloud project we also read who holds which role on the project (the email addresses of the people, groups and service accounts in its access policy), whether a bucket is shared with the public, and the service accounts with the creation dates of their keys — never the keys themselves. We never read the files, database contents or secrets those resources hold, and we never change anything in the account, subscription or project, tags and labels included.

From a connected GitHub organization (and, in the same way, a GitLab group or a Bitbucket workspace, as far as each service reports it) we read whether it requires two-factor authentication; each member's username, name, role and whether two-factor authentication is on, with the email address GitHub shows for them on the organization's verified domains or on their public profile; outside collaborators and pending invitations; each repository's name, visibility and branch protection settings; for pull requests merged in the last 90 days, the title, who wrote, approved and merged each one and whether its automated checks passed; and open dependency or vulnerability alerts (the affected package and version, the advisory and its severity) and secret-scanning alerts (only the type of secret and the repository). We never read code or other files, commit contents, pull-request or review text, comments, issues, build logs or the secrets an alert found, and we never change anything in the code host.

From a connected Cloudflare account we read the account's members (name, email, roles and whether two-step sign-in is on) and each site's security settings — encryption mode, minimum TLS version, HTTPS redirects, HSTS, which web application firewall rulesets are deployed and DNSSEC status — and whether the account's audit log can be read, keeping only the time of its latest entry. We never read DNS records, traffic, analytics or visitor data. From a client's OpenAI or Anthropic (Claude Console) organization, connected with an admin key, we read its members (name, email, role and when they joined), pending invitations, projects or workspaces, and each API key's name, project or workspace, owner or creator, status and the dates it was created and, where reported, last used. We never read prompts, responses, files, usage or billing, or the keys themselves.

From a connected Datadog organization or Splunk Cloud stack we read its users (name, email or username, roles, whether they sign in through single sign-on or have two-step sign-in on, and when they last signed in), its roles and their permissions, how long each log index keeps data (with its size and, for Splunk, when the latest entry arrived), the organization's single sign-on settings, and its security alerts, detection rules and monitors — their names, whether each is on, muted or switched off, and what kind of destination it notifies (email, chat, paging), not the addresses — and whether its own audit trail is recording. We never read log contents, search results, security signals, audit entries, metrics or traces, never run a search, and never change anything in Datadog or Splunk.

Credentials for connected tools (keys, secrets and tokens) are encrypted before they are stored and are deleted when the connection is removed.

Documents imported from SharePoint, OneDrive or Google Drive

When someone imports documents, we read only the files and folders they pick in Microsoft's or Google's own file picker (and, if they choose to keep watching a folder, the files in that folder). Imported files are stored like any other upload.

Billing information

Payments are handled by Stripe. We store the Stripe customer and subscription identifiers and the plan status; card numbers never reach our servers.

Email

We send service emails (sign-in links, confirmations, security notices, reminders and summaries). We keep a record of each email sent (recipient, subject and content, with sign-in links and codes removed, and the names and sizes of any attachments — not the attached files) so delivery problems can be investigated. A workspace can have email to its clients sent from its own domain; we then share that domain name with our email provider to verify it, and those emails show the workspace's sender name and address.

Cookies and browser storage

We use only cookies needed for the Service to work: your sign-in session (or, for an auditor invited to an audit, a separate session limited to that audit's pages), short-lived cookies that protect sign-in and connection flows, your light/dark theme choice and the last client you viewed. Your browser also remembers interface preferences such as whether the AI panel is open. We do not use advertising cookies or third-party analytics.

Patient information

Hardenwell GRC is built to hold information about security programs, not patient records. Please do not enter or upload protected health information (PHI) or other patient information unless your organization has signed a business associate agreement (BAA) with us. Upload screens remind people of this, and when AI reading is turned on it flags documents that appear to contain patient information.

How we use information

  • To provide the Service: store and show workspace content, run connected-tool checks, build documents and reports, and send the emails people ask for or that the Service needs to send.
  • To keep the Service and accounts secure: two-step sign-in, rate limits, detecting misuse, and investigating incidents.
  • To bill workspaces and provide support.
  • To improve the Service using information about how it is used in general (for example, which connections customers ask for). We do not use workspace content to advertise to anyone.

We do not sell personal information, and we do not share it for advertising.

AI features

Some features use artificial intelligence: the assistant, document and evidence analysis, suggested answers and maturity levels, document drafting, vendor reviews, drafting answers to customers' security questionnaires, matching an auditor's request list to evidence, files attached in the assistant, and scheduled AI jobs a workspace sets up (for example a weekly status note), which send the job's facts — such as control, vendor, document and staff names, never email addresses or document text. When these features are used, the relevant workspace content (for example, the document being analyzed, a summary of a client's assessment, or a customer's questions together with the client's approved policy passages, control status and saved answers) is sent to our AI provider, Anthropic, to produce a response. Documents flagged as appearing to contain patient information are not used as sources when drafting. Our provider processes this content under commercial terms that do not allow it to use the content to train its models. AI suggestions are never applied until a person accepts them. Workspace administrators can turn AI features off, in whole or feature by feature.

When someone chooses "Find obligations with AI" on a contract, Hardenwell GRC sends the text of that contract file, with the client's and the other party's names, to our AI provider (Anthropic) to list the obligations it contains; files that look like they contain patient information are not sent, and nothing the AI suggests is saved as an obligation until a person accepts it. If an organization turns on the question box on its trust center, the questions visitors type are sent to our AI provider together with content that trust center already shows publicly, and each question and its answer are kept so the organization can see what was asked; we don't store the visitor's IP address — only a keyed hash of it, kept for up to 30 days, to limit how many questions can be asked.

Google user data

If you sign in with Google, connect a Google Workspace account, or import documents from Google Drive, we access Google user data as follows:

  • Sign in with Google: your Google account identifier, name and email address, used to sign you in.
  • Google Workspace connection (read-only administrator access approved by the Workspace administrator): user and directory information (for example, whether 2-Step Verification is enforced, administrator roles, org units and inactive accounts) and mobile and ChromeOS device status, used to answer the client's assessment questions and keep evidence. If the administrator also grants it, group memberships (admin.directory.group.readonly, used to show each person's groups) and OAuth token grant records (admin.reports.audit.readonly, used to list the third-party apps people gave access to, counted per app). The connection can be made by a Workspace super administrator signing in with Google and approving this read-only access for Hardenwell GRC, or with a service account the client sets up. When an administrator signs in, we receive their email address and their Workspace's domain and customer ID (used to confirm they are a super administrator, to show who connected it and to keep each Google Workspace connected to only one Hardenwell GRC workspace), and we keep an encrypted refresh token so the scheduled checks can keep reading the same information as that administrator; we never see their Google password. The administrator can remove this access at any time under third-party connections in their Google Account or in the Google Admin console (API controls), and disconnecting the connection in Hardenwell GRC deletes the token and asks Google to revoke it.
  • Google Drive import (drive.file access): only the files you choose in the Google Picker, used to store them as documents for review.
  • Google Cloud connection (a service account the client creates in its own Google Cloud projects, with the read-only Viewer and Security Reviewer roles): resource settings, project access policies and service account key dates, as described under connected tools above. The service account's key is stored encrypted and the client can delete it at any time in its Google Cloud console.

We use this data only to provide and secure these features for the workspace and client that connected it. We transfer it only as needed to provide them (for example to our hosting provider, and to our AI provider when someone in the workspace uses an AI feature for that client, under terms that don't allow it to train on the data), to comply with the law, or as part of a merger, acquisition or sale of assets, with notice to you. We do not sell it, use it for advertising, or use it to develop, improve or train generalized artificial intelligence or machine learning models. People at Hardenwell Cybersecurity Advisors LLC do not read it except with your permission, to investigate a security issue or abuse, or to comply with the law.

Hardenwell GRC's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Microsoft user data

Signing in with Microsoft uses your Microsoft account identifier and email address. A Microsoft 365 connection uses read-only permissions that the client's Microsoft administrator approves (for example, users, groups and their sign-in methods, directory roles, security policies, sign-in logs, app consents, managed devices (including whether a phone is jailbroken), their antivirus status and the apps detected on them (searched only for a password manager or antivirus, as above), and security alerts, and — only if the administrator grants it — each mailbox's type, such as shared or room, and the device compliance policies that set screen lock and firewall rules) to collect the settings and summary information described above. The administrator can withdraw this access at any time by removing the Hardenwell GRC app in Microsoft Entra.

Who we share information with

  • People in the workspace, according to the roles the workspace owner assigns. Client users see only their own organization's information.
  • People the workspace chooses to share with, such as auditors it invites, vendors answering a questionnaire, or visitors to a trust center page the workspace publishes.
  • Service providers that run parts of the Service for us under contracts that limit how they may use the information: hosting and database, file storage, email delivery, payments (Stripe) and AI (Anthropic). Our Subprocessors page lists each one, what it does and where.
  • The tools a workspace connects, which receive the requests needed to read the information described above.
  • When required by law, or to protect the rights, safety and security of our users, clients or the Service.
  • In a business transfer, such as a merger or sale, where this policy will continue to apply to the information transferred.

How long we keep information

  • Workspace content is kept while the workspace exists. When a workspace owner deletes a workspace, its clients, content and uploaded files are deleted from the Service; copies in backups are removed as those backups expire.
  • Connected-tool credentials are deleted when the connection is removed.
  • Account information is kept while you have an account. You can ask us to delete your account at any time.
  • Failed sign-in records are deleted after 30 days; expired sessions and links are cleaned up automatically. An auditor's sessions last at most 12 hours and end when the audit closes or their access is removed.

Security

Connections to the Service use encryption in transit (HTTPS). Passwords are hashed, credentials for connected tools are encrypted, two-step sign-in is required by default, access inside a workspace follows the roles its owner sets, and changes are recorded in the activity log. No system is perfectly secure, but we work to protect your information and will notify affected customers of a security incident as required by law and our agreements.

Your choices and rights

  • You can see and update your name, email address, password and two-step sign-in methods on your account page.
  • Workspace owners can export documents and reports, and can delete clients or the whole workspace.
  • You can ask us for a copy of your personal information, to correct it, or to delete it by emailing admin@hardenwell.com. Depending on where you live, you may have further rights under privacy laws (for example, in California); we will honor them as those laws require and will not discriminate against you for using them.

Children

The Service is meant for businesses and is not directed to children. We do not knowingly collect information from anyone under 16.

Where information is processed

We host the Service in the United States. If you use it from elsewhere, your information will be transferred to and processed there.

Changes to this policy

If we make material changes, we will update the date at the top and, where appropriate, notify workspace owners by email or in the Service before the changes take effect.

Contact us

Questions or requests about privacy: admin@hardenwell.com