Common Security Questions

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.

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.

Is Grooper SOC compliant?

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

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

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.