Export jira maintenance records for cmmc that show what maintenance was requested, approved, performed, validated, and closed: issue details, timestamps, assignees, approval history, linked change records, test results, attachments, and Jira audit logs. For MA.L2-3.7.1, the goal is not to export every Jira ticket; it is to produce a reliable evidence set proving your organization performs corrective, preventative, adaptive, and perfective maintenance on in-scope systems.
NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice MA.L2-3.7.1 require that system maintenance is performed. An assessor will usually want more than a policy saying maintenance happens. They need records that connect a maintenance need to actual work on a system, including enough context to determine who did it, when it happened, and whether the result was checked.
What evidence taxonomy should you use for Jira maintenance records for CMMC?
Use a simple evidence taxonomy so that every maintenance record has a predictable home, responsible person, and collection schedule. As an SMB owner without a security team, you do not need a complicated governance program. You do need to avoid relying on one technician’s memory or on tickets that disappear after an employee or MSP relationship changes.
- Maintenance request artifact: The Jira issue describing the need for maintenance, affected system, reason, priority, and maintenance category. Source: Jira Service Management or Jira Software project. Owner: IT lead, MSP service manager, or system owner. Cadence: Created for each maintenance event; reviewed monthly.
- Work-performance artifact: Technician work logs, comments, status transitions, and time entries showing that maintenance actually occurred. Source: Jira issue activity and worklog export. Owner: Technician performing the work. Cadence: Recorded during or immediately after work; exported monthly.
- Approval artifact: Change approval, customer approval, or internal approval for maintenance that could affect availability, security, or configuration. Source: Jira approval field, linked change ticket, or approval comment from an authorized person. Owner: System owner or business owner. Cadence: Per applicable change.
- Validation artifact: Evidence that the patch, repair, upgrade, or configuration change worked as intended. Source: Jira attachment, linked monitoring alert, vulnerability scan result, screenshot, test result, or post-maintenance comment. Owner: Technician and reviewer. Cadence: Per maintenance event.
- Exception artifact: A documented reason a patch or maintenance action was deferred, including compensating safeguards and a target date. Source: Jira issue, risk register link, or approved exception record. Owner: Business owner and IT lead. Cadence: Reviewed at least monthly until closed.
- Maintenance program artifact: Recurring maintenance schedules, patch-management reports, asset lists, and ticket workflow settings that show maintenance is systematic rather than ad hoc. Source: Jira recurring automation, RMM platform, endpoint management tool, and documented procedures. Owner: IT lead or MSP account manager. Cadence: Quarterly and before an assessment.
Keep the ticket itself as the primary index. If a patch report lives in Microsoft Intune, NinjaOne, Huntress, or a firewall management console, attach the exported report to the related Jira issue or link it using a stable file location. The assessor should not have to search across five systems to understand one maintenance event.
Which Jira artifacts should be in your maintenance evidence inventory?
| Artifact to collect | Where it lives | What it proves | Owner | Collection cadence |
|---|---|---|---|---|
| Closed maintenance issues with issue key, summary, status, priority, reporter, assignee, created date, resolved date, and affected asset | Jira project export using CSV or API | Maintenance was identified, assigned, and completed | IT lead or MSP service manager | Monthly |
| Issue history and status-transition history | Jira issue activity and changelog API endpoint | Work followed a controlled workflow and was not simply marked complete without traceability | Jira administrator | Monthly |
| Technician comments and worklogs | Jira issue activity and worklog export | Specific actions performed, dates, personnel, troubleshooting, and completion details | Assigned technician | Monthly |
| Linked change requests and approval records | Jira issue links, Jira Service Management approvals, or linked change project | Higher-impact maintenance received authorization before implementation | System owner | Per change; export monthly |
| Patch deployment or vulnerability remediation reports | Microsoft Intune, NinjaOne, ConnectWise RMM, Automox, or vulnerability scanner export attached to Jira | Preventative maintenance was deployed and the underlying issue was remediated or tracked | MSP technician or internal IT lead | Monthly |
| Post-maintenance validation evidence | Jira attachment, test checklist, monitoring report, or issue comment | The maintained system was checked for successful operation | Technician and reviewer | Per maintenance event |
| Deferred-maintenance tickets and approved exceptions | Jira issue with “Deferred” status, due date, risk rating, and approval | Known maintenance gaps are managed rather than ignored | Business owner | Monthly review |
| Jira project configuration and automation rules | Jira administration screens; exported screenshots or configuration record | Recurring maintenance work is consistently created and routed | Jira administrator | Quarterly |
For a small company, use fields that make exports useful: Maintenance Type, Affected Asset, Maintenance Window, Validation Result, and Approval Required. A ticket labeled only “Server update” is weak evidence. A ticket stating “Apply June 2026 Windows Server cumulative update to FS-01; validate backup agent, file shares, and endpoint monitoring after reboot” is meaningful evidence.
How can you automate collection without creating more work?
Automation should collect a defensible copy of maintenance evidence, not replace technician documentation. Start with a saved Jira filter that returns completed maintenance work. For example, a Jira project named OPS could use this JQL query:
project = OPS
AND "Maintenance Type" in
("Corrective", "Preventative", "Adaptive", "Perfective")
AND statusCategory = Done
AND resolved >= startOfMonth(-1)
ORDER BY resolved ASCSave the filter as MA-L2-3.7.1 Completed Maintenance - Monthly. On the first business day of each month, export the previous month’s matching issues to CSV and PDF, including all available fields. CSV is useful for sorting and review; PDF or issue-print exports are easier for an assessor to read.
If you have Jira Cloud and someone comfortable with basic scripting, use the REST API to create a monthly JSON archive that includes issue history. This example pulls matching issues and requests the changelog, comments, worklogs, and attachments metadata:
curl --request GET \
--url "https://yourcompany.atlassian.net/rest/api/3/search/jql?jql=project%20%3D%20OPS%20AND%20statusCategory%20%3D%20Done%20AND%20resolved%20%3E%3D%20startOfMonth(-1)&maxResults=100&expand=changelog" \
--user "$JIRA_EMAIL:$JIRA_API_TOKEN" \
--header "Accept: application/json" \
--output "MA-L2-3.7.1-jira-maintenance-2026-07.json"Store the API token in your password manager or an approved secrets vault, not in the script. Also restrict the token to a Jira account with read-only access to the relevant project whenever possible.
In one practical example, a 28-person managed service provider supporting several regulated customers uses Jira Service Management for its internal operations. Its technicians create maintenance tickets from NinjaOne patch alerts and scheduled monthly Windows patch tasks. The service manager runs the saved filter each month, exports closed tickets, and attaches the NinjaOne patch compliance report to a single monthly evidence ticket. That one parent ticket links to the individual server, firewall, and endpoint maintenance records, making review manageable for a business owner.
Where should you store maintenance exports and how long should you retain them?
Keep exports outside Jira as well as inside it. Jira is the working system, but an external evidence repository protects you from deleted issues, permission changes, subscription changes, or a future MSP transition. Use a restricted SharePoint document library, Microsoft Teams-connected SharePoint site, Google Drive folder with controlled access, or encrypted file repository.
Create a predictable folder structure such as Compliance Evidence/CMMC L2/MA.L2-3.7.1/2026/2026-07. Store the monthly Jira CSV, PDF export, API JSON archive if used, patch reports, exception list, and a short index file or parent Jira export. Name files consistently, such as 2026-07-31_OPS-Maintenance-Export.csv and 2026-07_NinjaOne-Patch-Compliance.pdf.
Retain evidence according to your contract requirements, records policy, and assessment cycle. If you do not have a defined retention schedule, retain at least the current assessment period plus the prior period, and preserve longer records when a customer contract, incident, legal hold, or business requirement calls for it. More important than choosing an arbitrary number is documenting the rule and applying it consistently.
Limit write access to the people who collect evidence. Give the business owner read access, preserve version history, and avoid allowing technicians to overwrite finalized monthly exports. For especially important records, export a PDF and retain the original CSV or JSON alongside it so you have both a readable copy and a structured data copy.
How do you package maintenance evidence so an assessor can review it quickly?
Create one assessor-facing package for MA.L2-3.7.1 rather than handing over a large Jira export with no explanation. The package should begin with a brief evidence index that identifies the review period, systems covered, Jira project names, ticket workflow, and the person responsible for the evidence.
- Include a one-page explanation of how maintenance tickets are opened, categorized, approved when needed, completed, and validated.
- Provide the monthly closed-maintenance export for the selected period, preferably six to twelve months when available.
- Select a small representative sample of tickets: one patching event, one corrective repair, one adaptive change, and one deferred maintenance exception if applicable.
- For each sample, include the full issue record, comments, approval trail, linked reports, and validation evidence.
- Include the recurring-maintenance automation rule or schedule that creates regular patching and review tickets.
- Document any gaps honestly, including tickets that lacked validation details, and show the corrective process you adopted.
A 16-person IT provider serving smaller defense-contractor clients used this approach after discovering that its Jira tickets showed “Done” but did not consistently identify the affected asset. Rather than trying to rewrite old records, the owner preserved the existing exports, added an Affected Asset field to the workflow, trained technicians to attach patch reports, and opened a corrective action ticket documenting the improvement. That is far more credible than claiming the older records were complete.
Your next step is to create the saved Jira maintenance filter, export the last completed month, and identify the first three tickets that need stronger approval or validation evidence.
