Common Security Questions

Authentication and access control

What identity and access management systems are supported?

• Active Directory
• Microsoft Entra ID

Does Grooper support SSO? MFA enforcement?

Yes, Grooper supports Single Sign-On (SSO) through integration with enterprise identity providers. This includes Kerberos/NTLM-based Windows Authentication (e.g., via IIS) and OAuth 2.0-based authentication through Microsoft Entra ID.

When integrated with these providers, authentication policies such as Multi-Factor Authentication (MFA) are enforced at the identity provider level. This allows organizations to apply existing security controls—such as MFA, conditional access policies, and user access restrictions—without requiring separate configuration within Grooper.

Whether users are prompted for a username and password depends on the authentication mechanism and client environment rather than Grooper itself.

With Windows Authentication (Kerberos/NTLM via IIS), users may experience seamless SSO when Integrated Windows Authentication is supported (e.g., domain-joined machines and trusted browser configurations). In other scenarios, users may be prompted to enter credentials if automatic authentication cannot be negotiated. With OAuth-based authentication, users are redirected to the identity provider, where authentication (including SSO or credential prompts) is handled according to organizational identity and access policies.

Does Grooper maintain local accounts or is authentication fully federated?

Grooper does not maintain local application user accounts for interactive login. End-user authentication is fully federated through enterprise identity providers such as Active Directory (Windows Authentication) and Microsoft Entra ID (OAuth 2.0).

Within the system, there are also non-interactive service identities used for platform execution—such as IIS application pool identities and Grooper service accounts that perform background processing and workflow execution. These are infrastructure-level service accounts and are not used for end-user authentication or application access.

As a result, all human user access is governed through the organization’s centralized identity management system, while service accounts operate under standard Windows service security contexts.

How is access to files/data stored in a Grooper Repository restricted?

A Grooper Repository is composed of a SQL database and a Windows file store. User access to these resources are managed by your network security team.

• The Grooper app pool identity on the Grooper web server will need access.
• Accounts running Grooper services (such as Activity Processing) will need access.

What permissions does the Grooper app pool user need?

The Grooper "application pool identity" is a Windows account that runs the Grooper application installed on a Grooper web server. This account must be given certain permissions in order to launch the Grooper website in a web browser and run Grooper from that browser.

From a security standpoint, it is best practice to only give a minimum number of permissions to this account.

• It is unadvisable to give full local admin privileges to the Grooper application pool identity.
• The minimum number of permissions required are as follows:

Permission	Type	Reason
Always Required
Read Member Of	Active Directory	Required for checking user's group membership
Users	Local	Run the installed applications (Grooper)
File store access	NTFS\Share	Read and write access to the Grooper file store location
db_datareader db_datawriter	SQL database roles	Read and write access to the Grooper database
Conditionally Required
C:\Release	Local\NTFS	Run MsBuild for compiling Object Libraries and custom scripts in Grooper Required when implementing Object Libraries or other scripting.
Logon As Service	Local Security Policy	Run services installed via Grooper Command Console Required if also using the application pool identity as a service account running Grooper services

What permissions does the Activity Processing service user need?

The Activity Processing service automates task processing for Batches in Grooper. They need a minimum set of permissions in order to execute tasks.

Permission	Type	Reason
Users	Local	Run the installed applications (Grooper)
File store access	NTFS\Share	Read and write access to the Grooper file store location
db_datareader db_datawriter	SQL database roles	Read and write access to the Grooper database
Logon As Service	Local Security Policy	Run services installed via Grooper Command Console

Other Grooper services may require additional permissions. For example, an Import Watcher's user may need access to directories used for importing file content.

What permissions are required to run Grooper Command Console (GCC)?

Grooper Command Console (GCC) is a command line utility that performs various administrative tasks for Grooper. This includes Grooper Repository creation and Grooper service installation.

• GCC must be run as an administrator to perform most of its functions.
• When creating a Grooper database (databases create), the SQL user must have the dbcreator server role in SQL Server.
  • The SQL user is defined by the [user] and [password] parameters.
  • If these parameters are left blank, GCC will pass through the Windows credentials of the user running GCC.
• When connecting to a Grooper Repository (connections add), the SQL user must have at least db_datareader and db_datawriter roles in SQL Server.
  • The SQL user is defined by the [user] and [password] parameters.
  • If these parameters are left blank, GCC will pass through the Windows credentials of the user running GCC.
  • This user may require additional roles in SQL server to execute other GCC commands (see below).
• When initializing a Grooper Repository connection (connections init), the Grooper database's SQL user will need the db_owner role in SQL Server.
• When upgrading a Grooper Repository connection (connections upgrade), the Grooper database's SQL user will need the db_owner role in SQL Server.

Is HTTPS enforced when opening the Grooper web app?

Prior to Grooper version 25.0.0047 users could connect to the Grooper app using HTTP or HTTPS addresses. HTTPS is now mandatory. A trusted TLS/SSL certificate must be configured before installing or upgrading Grooper.

• Opening the Grooper web app over HTTP will fail or leave the application unnavigable.
• Existing deployments using HTTP must be updated to HTTPS.
• Exception: When accessed via localhost addresses, Grooper runs in "dev mode" and is allowed to operate over HTTP.

Supported certificate options:

• Self-Signed Certificate — Suitable for dev/test environments only. Requires manual trust installation on each client machine.
• Internal Certificate Authority (most typical) — Issued by your organization's internal PKI (e.g., Active Directory Certificate Services). Automatically trusted on domain-joined or managed devices. Ensure the internal root CA certificate is deployed on all client machines via Group Policy or device management tools.
• Public Certificate Authority — Trusted by all browsers and devices. Necessary only for internet-facing deployments. Examples: DigiCert, GlobalSign, Let's Encrypt.

How is user access to the Grooper application restricted?

The Grooper application is opened in a browser using a URL pointing to the Grooper web server. Users on your network who can access that URL will be able to open the Grooper application. Security can be applied to the web app in two ways:

• (Default) Windows Authentication (Active Directory credentials)
• Microsoft Azure Entra ID OAuth (Requires additional setup in Azure and on the Grooper web server)

Application users do not need access to the Grooper database or file store. Only the Grooper app pool identity and Grooper service accounts need access to the database and file store.

How is user access to a Grooper Repository restricted?

Use Permission Sets to restrict which users in your domain can access a Grooper Repository. Permission Sets allow users to determine access using Activity Directory users and groups. Access to the entire Grooper Repository can be blocked. Access to individual pages (Design, Batches, Tasks, etc.) can be blocked as well.

Restricting access to a Grooper Repository using Permission Sets is the best way to ensure only appropriate users can view Batch content.

How is access to different Batches or Review steps managed?

Review Queues filter what work is presented to a user in the Batches and Tasks page. Active Directory users and groups are assigned to a Review Queue. The Review Queue is then assigned to a Batch Process or Review step. Assigning the Review Queue to the Batch Process will filter out what Batches are available in the Batches page. Assigning the Review Queue to the Review step will filter out what Review tasks are available in the Tasks page.

Be aware, Review Queues are a work filtering mechanism, not a true security principle. They do act as a "soft security" measure by filtering out what work is available. However, if you want to completely lock down a user's ability to view a document, the most secure way to do so is remove their access to the Grooper Repository in its Permission Sets.

Compliance and testing

Is Grooper SOC compliant?

Yes. Grooper is SOC 2 compliant and undergoes a third party SOC audit annually.

How do you ensure application quality?

Grooper quality assurance is primarily validated through system testing performed on a fully deployed application in a controlled test environment. System tests cover end-to-end workflows and validate overall application behavior, including ingestion, processing, and output generation. Additional testing is performed as needed during development.

AI

When using Grooper's large language model (LLM) based features, does the LLM store your data or use it for training purposes?

Grooper does not persistently store raw LLM prompts or responses as part of standard processing. Instead, LLM outputs are used to drive downstream actions such as document classification or data extraction, with only the resulting structured data retained.

However, you should refer to the security and use policies of individual LLM providers to confirm if and how they store and use your data.

For OpenAI models

Grooper integrates with OpenAI API not Chat GPT. When using the OpenAI API, your data (prompts, completions, embeddings, and fine-tuning data) is not used for training to improve OpenAI models (unless you explicitly opt in to share data with OpenAI). Your data is not available to other customers or other third parties.

All data passed to and from OpenAI (prompts, completions, embeddings, and fine-tuning data) is encrypted in transit.

Data is saved in the case of fine-tuning data for your own custom models. Fine-tuned models are available to you and no one else (without your consent). All stored fine-tuning data may be deleted at your discretion. All stored data is encrypted at rest. The OpenAI API may store logs for up to 30 days for abuse monitoring. However, they offer a "zero data retention" option for trusted customers with sensitive applications. You will need to contact the OpenAI sales team for more information on obtaining a zero data retention policy.

See here for more on data controls in the OpenAI API.

For Azure AI Foundry Models (including Azure OpenAI models)

Azure AI models are deployed in Azure resources under your control in your tenant. Models are deployed in Azure and operate as a service under your control. Your data (prompts, completions, embeddings, and fine-tuning data) is not available to other customers, OpenAI, or other third parties. Your data is not used for training to improve models by Microsoft, OpenAI or any other third parties with out your permission or instruction.

All data passed to and from the model service (prompts, completions, embeddings, and fine-tuning data) is encrypted in transit.

Some data is saved in certain cases, such as data saved for fine-tuning your own custom models. All stored data is encrypted at rest. All data may be deleted at your discretion. Azure will not store prompts and completions without enabling features that do so. Azure OpenAI may store logs for up to 30 days for abuse monitoring purposes, but this can be disabled for approved applications.

See here for Azure AI Foundry's data privacy summary

See here for Azure's OpenAI data privacy policies

My organization does not want to use Grooper's large language model (LLM) based features. How do I prevent users from using LLMs in Grooper?

LLM connectivity is allowed in Grooper by adding an LLM Connector. If you do not want to use LLM features, do not add an LLM Connector to the Grooper Repository.

What AI governance controls does Grooper have?

Grooper does not currently implement dedicated, automated technical controls specifically for prompt injection detection or data leakage prevention at the LLM layer.

LLM behavior is governed through configurable instructions, which allow organizations to guide how models interpret inputs and structure outputs. However, these instructions are not inherently resistant to adversarial prompt manipulation and should not be relied upon as a sole control mechanism.

Grooper supports output validation through configurable platform features. For classification scenarios, outputs are constrained to predefined Document Types, limiting the range of possible model responses. For extraction scenarios, Data Models enforce required fields and data types, while Data Rules enable the application of business-specific validation logic. Output is further verified by incorporating review steps into the process.

Additionally, Grooper provides grounding capabilities through features such as Spatial Grounding, which associate extracted values with their source locations in the document. This enables traceability and facilitates verification of LLM-derived outputs against the original content. However, Grooper does not have fully automated LLM-specific output validation guardrails (e.g., semantic correctness enforcement or hallucination detection)

Risk mitigation is achieved through a combination of workflow and access controls, including restricting which users can configure or execute LLM-enabled processes, limiting the data provided to LLMs through process design, and incorporating human-in-the-loop review steps.

In on-premises deployments, all processed data and results remain within infrastructure controlled by the client. Data protection measures such as encryption at rest and in transit are implemented at the infrastructure level and are the responsibility of the deploying organization. If external LLM services are used, any data transmitted to those services is subject to the configuration and policies defined by the client.

Grooper does not persistently store raw LLM prompts or responses as part of standard processing. Instead, LLM outputs are used to drive downstream actions such as document classification or data extraction, with only the resulting structured data retained.

Visibility into LLM inputs and responses is limited to diagnostic and testing contexts, where this information is rendered transiently in memory for the duration of an active session and is not retained after the session ends.

Organizations are responsible for implementing appropriate governance practices, including prompt design review, data exposure controls, and output validation, in accordance with their internal security and compliance requirements.

Security Stance

Grooper is built with security as a core design principle, hardened at the application layer through secure coding practices, encrypted data handling, role-based access controls, and a commitment to timely vulnerability remediation.

Because our software is deployed within your own infrastructure, the overall security of the system depends equally on the environment it runs in. We operate on a shared responsibility model:

We Are Responsible For

• The security of the application code and its dependencies
• Authentication and authorization mechanisms
  • Grooper does not maintain local application user accounts for interactive login
  • Access is fully federated through enterprise identity providers — Active Directory (Windows Authentication) or Microsoft Entra ID (OAuth 2.0) depending on install path
• Enforcing HTTPS at the application level — Grooper now requires HTTPS to operate and will not function correctly over an unencrypted connection
• Producing application updates, including updates to security, and communicating when updates are available or recommended
• Designing database connectivity around dedicated service accounts
  • The app pool account and processing service accounts require connectivity to the Grooper database. No other user requires access.
  • In each case, Grooper is designed to operate with the minimum permissions required for their function, in line with the principle of least privilege.

You Are Responsible For

• The security of the servers and operating systems hosting the application
• Network configuration, firewalls, and access controls
• Enforcing HTTPS for all user-facing access to ensure data is encrypted between users and the application
• Enabling TLS on internal connections to ensure end-to-end encryption within your environment
• Enabling encryption at rest on the database and file store layers hosting application data
• Installing application updates — no changes to the installed application occur without you deploying a new build. We strongly recommend establishing a regular update cadence.
• Assigning permissions to application service accounts during deployment
• Using Permission Sets to define user access to the Grooper Repository and rights within
• Physical and cloud infrastructure security
• Monitoring and logging at the infrastructure level

Common Concerns

• Encryption in transit — Grooper is designed to operate over HTTPS, ensuring data in transit is encrypted at the transport layer. Current versions of Grooper enforce this by requiring HTTPS to operate. Internal traffic encryption — between the application and database, or between services — depends on your infrastructure configuration, and we strongly recommend enabling TLS on all internal connections.
• Encryption at rest — Data at rest is encrypted when your database and file store layers have encryption enabled. Grooper is designed to sit on top of encrypted storage — enabling encryption at the infrastructure level ensures application data is protected at rest.
• Account access — Only service accounts — the app pool account and service accounts — require access to the Grooper database and file store location. The application is designed to operate under least privilege. The permissions granted to those accounts are set by you during deployment.
• Application access — End-user authentication is fully federated through enterprise identity providers such as Active Directory (Windows Authentication) and Microsoft Entra ID (OAuth 2.0). Ensure only correct users and groups have access to the Grooper Repository and major areas through page access restrictions using Permission Sets.

---

A well-secured deployment is a partnership. Our application will perform as securely as the environment it is placed in — strong infrastructure means a strong overall security posture.

We are happy to provide deployment security guidelines, architecture recommendations, or answer any questions to help you configure your environment with confidence.