Safe & Secure HR Service Management: How to Protect Sensitive Employee Data

[#1]

Human Resources teams handle some of the most sensitive data in an organization from employee requests to confidential complaints and investigations. Implementing HR Service Management on JSM requires careful configuration of security features to ensure privacy and compliance. In this primer, we’ll walk through key JSM security features – Project Access Controls, Project Permissions, Customer Permissions, Issue Security Schemes, Request Type Restrictions, and Confidential Fields – and map them to HR use cases (onboarding, termination, compliance requests, investigations). We also highlight the risks of not using these features and compare the HR service desk experience with vs. without proper security controls.

Security - No compromise and No workarounds

HR service desks often deal with requests that “only few need to be involved,” such as employee relations cases or termination plans . A lack of proper controls can lead to data leakage, unauthorized access to personal data, or even compliance violations (e.g. exposure of PII violating GDPR). The goal is to create a safe space for HR to operate, while still providing great service to employees.

Project-Level Access Controls

At the highest level, you should restrict access to the HR project so that only authorized HR business partners can even see it. In JSM, projects can be made “private” by controlling membership and permission schemes. This means only adding HR team members (as agents) to the project and excluding all other users from roles that grant project access.

• Configure a Private Project: Ensure the project’s permission scheme limits the “Browse Projects” permission to the HR team (e.g. the Service Desk Team role or a specific HR group). Do not use broad groups like “employees” or “jira-users” for browse/view permissions. In practice, only the people on your HR service desk should be added to the Service Desk Team role (and perhaps a designated HR Managers role) . This prevents any other logged-in users from accessing the project.
  
  
• Internal vs. Public Projects: Marking the HR project as internal/private is critical. Unlike IT support projects that might be open to all employees, an HR project should be locked down.
• Risks of Not Restricting Project Access: If the HR project is left “open” (accessible to all users by default permission), any user could search or browse HR tickets. For example, without restriction an IT analyst might stumble upon an HR issue containing salary info or a performance complaint. Keeping the project private ensures sensitive HR data is only visible to the HR staff who need it .

Project Permissions and Roles

JSM uses permission schemes to grant specific rights (browse, comment, transition issues, etc.) to users, groups, or roles. For an HR service project, you’ll want to carefully tailor these permissions:

• Define HR Roles: Use project roles to separate different HR functions if needed. For example, you might have a “HR Agents” role (for general HR service desk team), an “HR Managers” role (with oversight permissions), and possibly an “Approvers” role if managers will approve certain HR requests. Each role can be mapped to groups of users.
  
  
• Permission Scheme Setup: Copy the default JSM permission scheme and modify it for HR. Grant “Browse Projects” and “View Issues” only to HR roles (and Jira admins as needed). Allow “Edit Issues”, “Add Comments”, “Transition Issues”, etc. to the HR Agents role (the core team working on tickets). You might grant “Add Comments” to HR Managers as well if they need to contribute notes. In general, avoid granting any permissions on the HR project to non-HR personnel. Every company-managed project has a scheme that you can edit in Project settings > Permissions – JSM even allows project admins (not just global admins) to adjust these, but do so cautiously for HR.
  
  
• Customer vs. Agent Actions: Remember that customers (employees) raising HR requests via the portal do not use the Jira permission scheme for actions – they have a limited set of abilities (they can create requests, add attachments, and comment publicly on their own tickets). Agents (HR team members with JSM licenses) use the permission scheme. Ensure that only agents have the ability to view internal comments or edit issues. For example, configure the scheme so that internal comments (JSM “Add comment internally”) are only available to agents, whereas customers can only add “public” comments via the portal. By default, JSM handles this separation, but verifying the permission scheme is important.
  
  
• Practical Example: In an onboarding request scenario, an HR agent will have rights to transition the workflow (e.g. move the ticket through steps like “Documents Received” or “Account Created”), while the requesting employee (customer) can only see status and add comments. If your scheme is too open, a non-HR collaborator might inadvertently be able to transition or view things they shouldn’t. Always test the scheme with a non-HR user to ensure they cannot browse or find the project.
• Risks of Poor Permission Setup: If project permissions are misconfigured, you could end up granting unintended access. For instance, granting “Browse Projects” to all logged-in users would expose the HR project contents (even if they’re not in HR). Granting “Add Comment” or “Assign Issues” to a broad group could allow outsiders to interfere with HR tickets. The experience without proper permissions might include unauthorized edits to issues or visibility of private comments. With a correct scheme, only the HR team can work on and see the issues, preserving confidentiality.

Customer Permissions (Portal Access)

HR service desks often serve an internal customer base (employees and managers). JSM’s Customer Permissions settings control who can raise requests in the portal and who can see or share those requests. Configure these to enforce privacy:

• Who Can Raise Requests: In Project settings > Customer permissions, choose a restricted option for who can create requests. Typically, for HR you will allow only specific people (employees) to access the portal, not the general public. For example, set “Who can raise requests?” to “Customers added by agents and admins” (meaning HR team must invite or add each customer) or to “Anyone with an account on this Jira site” if all employees have accounts . The latter still limits it to your company’s domain if self-signup is off. Avoid “Anyone can email or sign up” for HR projects, as that could let external people submit requests.
  
  
• Who Customers Can Share With: To prevent sensitive HR tickets from being shared broadly, choose the most restrictive sharing setting. The safest approach is to allow customers to share only with their own organization (or with no one at all). If you organize employees into JSM Organizations (e.g. by department), you might still keep this to “other customers in their organization” . Often, however, you might put each employee in a unique organization (so that effectively they cannot share tickets with anyone else). This ensures HR requests remain private to the reporter by default. In an HR context, you likely don’t want an employee seeing another’s request unless explicitly authorized.
  
  
• Portal Visibility: By default, customers can only see their own requests (unless shared). This is good for HR. Make sure the setting “Other customers can search for requests” is NOT enabled for an HR project. In summary, configure it such that employees can raise their own tickets, but cannot browse a list of others’ HR tickets.
  
  
• Use Case – Onboarding: Typically, a hiring manager or IT might raise an onboarding request on behalf of a new hire. Using customer permissions, you can allow internal managers to access the HR portal. You might create an Organization for managers or simply add them individually as customers. When they raise a request, it remains visible only to them (and HR). Without proper customer permissions, if the portal were open to all, a malicious outsider might submit bogus requests or a curious employee might try to access a request type not meant for them.
• Risks if Left Open: Without tight customer access control, uninvited users could submit HR requests (e.g. a former employee or outsider finding the portal email). Worse, if “share with anyone” is allowed, an employee could accidentally share their sensitive ticket with a coworker or the whole organization. By contrast, with proper customer permissions configured, only current employees can raise HR tickets, and each request’s visibility is limited.

Issue Security Schemes (Issue-Level Security)

While project-level permissions restrict who in general can access the project, Issue Security Schemes provide fine-grained control over which specific issues can be seen by which people. Issue security is critical in HR scenarios where some tickets need tighter confidentiality than others (e.g. a general HR inquiry vs. a sensitive investigation).

What is an Issue Security Scheme? It’s a configuration that defines one or more security levels, which can be applied to issues. Each security level lists the users, groups, or roles that are allowed to view issues with that level. If an issue has a security level, only those users can view/comment on it – others (even if they are project agents) won’t see it in searches or boards . If no security level is set on an issue, it defaults to project permissions visibility.

• Setting Up a Scheme: As a Jira admin, create a new issue security scheme (via Jira Settings > Issues > Issue Security Schemes). Define security levels such as “Standard HR Access” and “Confidential HR Only” (you can create multiple levels to map to different sensitivity tiers). For each level, add the appropriate roles/groups:
• The “Standard HR Access” level might include the HR Agents project role (all HR team members) and perhaps HR Managers role, as well as the special JSM role “Service Project Customer - Portal Access” (this role represents the issue’s reporter and any request participants on the portal) . Including the customer role is important so that the employee who raised the request can see their own issue in the portal.
• The “Confidential HR Only” level could include only a subset – e.g. an “HR Managers” group or a specific group like Employee Relations Team for investigations, plus the Jira addon user role (so that automation or apps can still see the issue) . If the issue is so sensitive that even the original reporter should not see updates (e.g. an investigation initiated by HR about an employee), you might not include the customer role on that level. (In such cases, the issue wouldn’t be visible on the portal to the employee.)

Example of an Issue Security scheme with multiple levels (e.g., a “Private Issue” level for confidential matters restricted to HR, and a normal level for general HR tickets). Each level will have a list of roles/groups who can view issues at that level.

• Applying Security Levels: After associating the scheme to the HR project, you can apply security levels to issues. Add the “Security Level” field to the issue screens and request forms. For instance, you may set a default security level for all new issues. Atlassian recommends setting a default level so that if users forget to choose one, it doesn’t default to “None” (visible to all) . In an HR project, you might set the default to “Standard HR Access”. Then, configure automation or manual processes for certain request types/issue types to switch to “Confidential HR Only” when needed (for example, if an issue is of type “Investigation” or request type “Report Misconduct”). JSM now even allows you to tie security levels to request types or set them via automation for specific categories .
  
  
• HR Use Case Mapping:
  
  
  • Onboarding and Routine HR requests: These can use the default security level (visible to the whole HR team). It allows any HR agent to assist and cover for others, and the reporting employee can see their ticket status.
    
    
  • Termination cases: You may restrict these issues to only a small group (e.g. senior HR and the employee’s manager) by applying a higher security level. The employee being terminated typically wouldn’t be the reporter in such cases; it might be initiated by HR or the manager, and you’d include only those roles in the security level.
    
    
  • Compliance or data access requests: If an employee requests “view my data” (GDPR request), they are the reporter so you’d include them. But if the ticket spawns sub-tasks or linked issues with actual data gathering, those might be at a higher security level internally.
    
    
  • Investigations and confidential complaints: These likely use the most restrictive security level – perhaps only HR investigators and HR leadership can view. For example, a harassment complaint might be filed via a portal (reporter is the employee or an anonymous alias). You could set the issue security so that only a specific “HR Investigations” group (and the reporter, if appropriate) can see it. Atlassian notes that internally they use a separate confidential project for such cases , but you can achieve similar segregation with issue security in one project.
    
    
• Risks Without Issue Security: If you rely solely on project permissions, all HR agents see all HR tickets. This could be problematic – e.g. an HR intern could see an executive’s complaint about another executive, or a recruiter could see confidential performance improvement plans that they don’t need to see. The experience without issue security is “all-or-nothing”: either you create many separate projects (siloing information) or everyone on the project has full visibility. By using issue security, you avoid having to split into too many projects while still controlling visibility on a need-to-know basis . It greatly reduces internal data leakage risk. Even Jira admins cannot see an issue if they are not included in its security level , which is a good thing for HR confidentiality (administrators can always add themselves via scheme configuration if absolutely needed, but they aren’t automatically able to snoop).
  
  

Tip: When using issue security in JSM, always include the Service Project Customer - Portal Access role (which covers the reporter and participants) on levels where the reporter should still see their issue . Otherwise, employees might lose access to their own requests without explanation. Also ensure the “Set Issue Security” permission is granted to the right people (so HR agents can choose levels, or use automation to set it) .

Request Type Restrictions

Jira Service Management introduced Request Type Restrictions to complement issue security by controlling who can create certain request types on the portal. This feature is perfect for HR scenarios where some request forms should only be used by specific people (e.g. managers or HR staff), and hidden from others . In other words, even if someone is a customer in the project, they may not see all request options unless they’re in an allowed group for that request type.

• How It Works: An admin can restrict a request type to certain users, groups, or organizations. If a request type is restricted, it won’t appear on the portal for users who are not granted access (even if they search for it) . For example, you might restrict a “Terminate Employee” request type to members of the “People Managers” group and the HR team. Regular employees would not even know this request type exists on the portal. Administrators and agents are also subject to these restrictions when using the portal or raising requests on behalf of someone – they must be included to see it (though agents can always create issues through the Jira interface if they have project access) .
  
  
• Configuring Restrictions: Go to Project settings > Request types. You’ll see a list of request types, and a padlock icon or “Restrictions” option for each. Click that and add the users/groups/organizations that should have access . Once applied, the request type will show a lock icon indicating it’s limited. Atlassian’s documentation gives the example of restricting an “Employee Pay Hike” request to just managers and HR . In HRSM, similarly consider:
  
  
  • Manager-only request types: e.g. “Request New Position” or “Employee Offboarding” might be visible only to people managers (and HR).
    
    
  • HR-internal request types: e.g. “Sensitive Case – Internal Use” only HR can create (agents could use the portal or the agent view to fill these, but employees cannot).
    
    
  • Executive requests: perhaps a request type only available to a specific VIP group, if needed.
    
    

Portal view of a restricted HR request type (“Fix an account problem” in this example). The lock icon and tooltip indicate that only specific people (e.g. certain roles or groups) can raise this request.

• Channels and Limitations: Note that restricted request types cannot be submitted via email or unauthenticated channels . This is intentional – if someone emails the HR support address, it will not magically create a restricted-type issue (it will either fail or go to a default type). This prevents anonymous users from bypassing restrictions via email or chat. Make sure that any email channel you configure for HR is for request types that are open to all employees. For highly sensitive types, consider disabling email channel to force the controlled portal usage.
  
  
• Request Types vs. Issue Security: It’s important to realize that request type restrictions only limit who can create the issue, not who can view the issue after creation . Viewing is still governed by project/issue security. So you often use these features together. For instance, you might restrict the “Report Misconduct” request to employees only (so only internal staff can submit it, not, say, contractors if they aren’t in the allowed group), and then also apply an issue security level on those issues so that only a subset of HR can view them.
  
  
• HR Use Case Integration:
  
  
  • For Onboarding: You may actually not restrict the “New Hire Onboarding” request type – you want all hiring managers to use it, possibly even any employee to request equipment for a new hire. If all employees should have access, keep it unrestricted. But if only HR should initiate onboarding (maybe via an internal form), you could restrict it to HR group so that employees don’t accidentally create onboarding tickets.
    
    
  • For Termination/Offboarding: Typically only HR or a manager should trigger an offboarding. So you can restrict “Employee Offboarding Request” to the HR team and managers group. Without this, an employee might see an “Offboard employee” form and (in a dark humor scenario) try to offboard their boss! With restrictions, such sensitive options aren’t visible except to authorized roles.
    
    
  • For Investigations or Complaints: You might allow all employees to submit a “Report an HR Issue” complaint – that one likely remains open to all employees (since any employee might need to report harassment). But you could have a separate request type used by HR internally like “Initiate Investigation” (for cases that come through other channels or require HR to create a case proactively). That internal type can be restricted to HR staff only (so no one on the portal sees it). This way, HR can create investigation issues without exposing that form to everyone.
    
    
  • For Compliance Requests: If an employee data access request should only come from the employee themselves, you might not need restriction (everyone should be able to request their data). However, if there’s a request type like “Legal Hold Notice” which should only be created by Legal/HR, restrict it accordingly.
    
    
• User Experience Without vs With Restrictions: Without request type restrictions, all employees see all request options on the HR portal, even those not relevant or not permitted. This can cause confusion or mistakes (employees might submit requests they shouldn’t) . For example, before this feature, one customer noted that all employees could see every HR request type, leading to cases of people accidentally using the wrong forms . With restrictions turned on, the portal is cleaner – employees only see what they are meant to use, which “keeps the request form uncluttered and easy to use” . It also adds a layer of security by obscurity: sensitive processes (like terminations) are not even advertised on the help center to regular staff.
  
  

Caution: Ensure you update documentation or communications so that the intended users of a restricted request type know how to access it. For instance, if managers are supposed to use the “Pay Adjustment” request, make sure they’re aware (since others won’t even see it). Also remember to update automation rules or links, if you have an automation creating issues of a restricted type, the automation’s actor must have access to that type or the rule won’t work .

In summary, treat your HR service project as a highly confidential system and configure it deliberately: private project access, least-privilege permissions, strict portal settings, granular issue security, and encrypted fields for sensitive data. The result will be an HR help desk that delivers excellent service to employees and keeps their personal information safe and secure.

[Josh]

Hi @Prabhu Palanisamy _Onward_ .

This article is helpful for outlining the tools admins have at their disposal to protect work items / data.

Have you given any thought to potential protections around instance backups (which do not respect these controls)? Anyone with access to the backups would be able to access all the data in plaintext...

[Prabhu Palanisamy _Onward_]

@Vish Reddy {Revyz} is my goto SME on backups. Vish may have a point of view on securing backups.