Analysis
HR is going to use the breakdown. Mostly it would be an audit of the time spent and some insights into areas where people are spending time.
This is a known anti-pattern. If the team is succeeding, then the Scrum Master (as part of the team) is contributing to its overall success. If the team is failing, then the Scrum Master (again, as part of the team) is failing alongside them.
The team succeeds or fails as a whole. Trying to tease out individual performance for team-based frameworks is an anti-pattern. The way to handle it is to educate the organization on how to effectively evaluate whole-team performance, not hijack ticketing systems like JIRA to track labor hours.
If you don't feel empowered to have that conversation, that's a problem too. Speak to your line manager, agile coach, or other project sponsor, and ensure that they are fully supporting Scrum's team-oriented culture. Doing anything else is an abdication of your responsibilities as a Scrum Master.
Recommendations
If the team is routinely failing to meet its Sprint Goals, then this is a problem for the entire Scrum Team to address during Sprint Retrospectives. Neither a traditional Project Management Office (PMO) nor Human Resources (HR)—and for goodness sakes, why is Human Resources even in this picture at all?!—should be involved in assessing intra-team processes or utilization.
While an agile community of practice is always a good source of advice and information, the organization should be looking at outcomes (e.g. "Is the team meeting its Sprint Goals more often than not?") rather than utilization metrics. Trying to convert individual hours into a value proposition is antithetical to core agile principles.
Tracking labor hours within the project is intrinsically a utilization metric, and to a lesser extent a cost-tracking or cost-accounting metric. When done properly at the program level, Scrum typically has an averaged run-rate per Sprint that is essentially fixed. Tracking labor hours instead of outcomes simply doesn't fit this model, except when the organization is violating core principles by matrixing teams or assigning people (a second anti-pattern) to multiple teams (a third anti-pattern). Don't do those things.
Don't enable organizational dysfunction or support known anti-patterns. Educating the organization on how the framework is meant to be applied, and how to be more agile in their business approach and interactions with the team, is an essential part of the Scrum Master's job.
One Caveat: Wage Accounting
If HR wants to know how many hours a day people are at work, or when they're taking time off, those are reasonable wage-related requests that have little to do with Scrum as a project management framework. Granular time tracking is an anti-pattern, though, so make sure you don't have an X/Y problem here.
Say "no" to utilization metrics, but by all means use techniques like the 5 Whys to understand the real problem that HR is trying to solve for. You may be able to help them solve for X rather than Y without damaging your Scrum implementation.
