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?

When installing the Grooper web client, you will need to assign an application pool identity — a Windows account under which Grooper runs. This account must be granted specific permissions to launch and operate the Grooper website.

From a security standpoint, this account should be granted the minimum permissions required to function. It is unadvisable to grant full local administrator privileges to the Grooper app pool identity.

Note: The user performing the installation must also have the ability to query the domain in order to enter credentials for the app pool identity during setup.

Permission	Type	Where to Configure	Reason
Always Required
Read Member Of	Active Directory	Active Directory Users and Computers (or via Group Policy)	Required to check the authenticated user's group membership at login
Local Users Group	Local	Computer Management → Local Users and Groups → Groups → Users	Grants rights to run installed applications, including Grooper
File Store Access	NTFS / Share	Windows Explorer → Folder Properties → Security (NTFS) and/or Share Permissions	Read and write access to the Grooper file store location
Database Access	SQL Server	SQL Server Management Studio → Security → Logins → [account] → User Mapping → [GrooperDB]	Read and write access to the Grooper database. Grant db_datareader and db_datawriter on the Grooper database.
Conditionally Required
C:\Release	Local / NTFS	Windows Explorer → Folder Properties → Security	Required when implementing Object Libraries or custom scripts — grants rights to run MSBuild for compilation
Logon As Service	Local Security Policy	Local Security Policy → Local Policies → User Rights Assignment → Log on as a service	Required only if the app pool identity is also being used as a Grooper service account

Note: The permissions above cover normal application operation. Elevated database rights — such as the ability to create or alter tables — are only required during initial installation or upgrades if alterations to the Grooper database tables are required or new tables are added. Furthermore, only the user running Grooper Command Console (GCC) will need these rights.

What permissions does the Activity Processing service user need?

Grooper services — such as the Activity Processing service — run under dedicated Windows service accounts to automate task processing for Batches. These accounts must be granted a minimum set of permissions to execute tasks.

From a security standpoint, service accounts should be granted only the permissions required for their function. It is unadvisable to grant full local administrator privileges or elevated database roles to any Grooper service account.

Permission	Type	Where to Configure	Reason
Local Users Group	Local	Computer Management → Local Users and Groups → Groups → Users	Grants rights to run installed applications, including Grooper
File Store Access	NTFS / Share	Windows Explorer → Folder Properties → Security (NTFS) and/or Share Permissions	Read and write access to the Grooper file store location
Database Access	SQL Server	SQL Server Management Studio → Security → Logins → [account] → User Mapping → [GrooperDB]	Read and write access to the Grooper database. Grant db_datareader and db_datawriter on the Grooper database.
Logon As Service	Local Security Policy	Local Security Policy → Local Policies → User Rights Assignment → Log on as a service	Required to run services installed via Grooper Command Console

Note: These permissions are sufficient for Activity Processing services and serve as a baseline for all Grooper services. Other Grooper services may require additional permissions depending on their function. For example, an Import Watcher service account may need read access to directories used as import sources. Always scope additional permissions to the minimum required for that service's specific function.

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, 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
• Enabling 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.
• Data Collection — Grooper does not collect document content, user data, or processing metadata. The only data transmitted to Grooper is volume counts for license compliance purposes. This connection is made via HTTPS. All other application data remains entirely within your infrastructure.
• Air-Gapped Environments — Grooper supports fully offline deployments via a license file. In this configuration no outbound connections are made and volume is tracked internally. If volume is exhausted before the reset period, contact Grooper directly to receive an updated license file.
• AI Use — AI capabilities are available as optional features and are not required for use of the platform. When enabled, AI functionality may utilize third-party AI services selected by the customer. Any data transmitted to such services is governed by the applicable third-party terms, security commitments, privacy policies, and Data Processing Agreements (DPAs). Customers are responsible for determining whether the use of third-party AI services meets their organizational and regulatory requirements.

---

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.