IT Security Risk Management Integration Guide

This guide is intended for Archer administrators and IT teams responsible for configuring and extending the IT Security Risk Management (ITSRM) solution. It explains how to plan, structure, and implement integrations with third-party tools so that external data enriches your information system records, informs risk decisions, and powers your ongoing monitoring program.

While Archer ITSRM includes a set of out-of-the-box (OOTB) integrations on the Archer Exchange, most organizations will want to connect additional tools specific to their environment. This guide covers the types of data worth bringing in, where that data surfaces within the ITSRM solution, the recommended setup path, and the technical methods available to build integrations.

Purpose of the ITSRM Solution

Archer ITSRM is an IT GRC solution designed to help organizations systematically manage IT security risk across their technology environment. The solution centers on the Information System record, which acts as the primary unit of analysis for understanding risk exposure at the system level.

At its core, the solution enables organizations to:

Document information systems, including their components, owners, and associated applications and devices.
Identify the business impact if a system were compromised, using a structured assessment of confidentiality, integrity, and availability.
Understand threats relevant to each system and evaluate the controls in place to mitigate those threats.
Perform ongoing monitoring of systems to track risk posture over time, including key risk indicators (KRIs), security events, and control effectiveness.
Drive remediation activity and track issues to closure.
Integrations extend this core capability by bringing real-time or near-real-time data from the tools already operating in your environment directly into Archer, reducing manual data entry and improving the accuracy and timeliness of your risk picture.

Why Integrations Help IT GRC

Archer ITSRM is an IT GRC tool. It is designed for documenting systems, assessing risk, understanding the controls in place, and tracking risk posture over time. It is not a Security Operations Center (SOC) tool, and it is not intended to replace the specialized platforms your organization already uses for vulnerability scanning, event management, ticketing, or configuration monitoring. Those tools are purpose-built for operational workflows, and they do that work well.

The goal of integrating with those tools is not to replicate their data inside Archer or duplicate their workflows. Bringing thousands of individual vulnerability findings or raw security events into Archer would create noise rather than insight, and it would put data into a platform that is not designed to manage it at that level of operational detail.

The value of integration lies in surfacing the right signals at the right level of abstraction, the kind of information that helps a risk manager or system owner answer GRC questions, not triage tickets. For example, rather than importing every vulnerability finding detected on a system, an integration might bring in a weekly count of severe vulnerabilities across that system. That single metric, tracked over time on the Ongoing Monitoring tab, gives a risk owner meaningful context: Is the number growing? Has it spiked since the last assessment? Does the volume suggest that the controls documented in Archer are not performing as expected, and that a reassessment is warranted?

This is the lens through which integrations should be planned. Ask not "what can I pull from this tool?" but "what signal from this tool would help me make a better risk decision in Archer?" The answer will almost always be a summary metric, a threshold breach, or a status indicator, not a raw data dump.

Where Integrations Play in Archer ITSRM

External data can feed into several areas of the ITSRM solution. Understanding where that data lands helps you plan what to integrate and how to structure the data before you build.

The Information System Record

The Information System record is the foundation of ITSRM. It consolidates everything known about a system, including its risk assessment, associated controls, and live monitoring data. Integration data influences two key dimensions of the risk assessment:

Impact

The impact score reflects how significant it would be if a system were compromised. External tools can supply metrics that help calibrate or validate this score. For example, a CMDB or configuration management tool may carry data about whether a system hosts sensitive data, the number of users it supports, or its classification level. Pulling this context into Archer ensures the impact assessment reflects current system attributes rather than information captured at initial documentation.

Likelihood

The likelihood dimension captures how probable it is that a system will be successfully attacked. Two integration patterns directly influence this:

Threat data integrations bring in external intelligence about active threats targeting technologies in your environment, helping assessors understand what they are actually up against.
Continuous control monitoring (CCM) integrations pull results from configuration scanners or compliance tools to show whether the controls recorded in Archer are actually functioning as designed. A control that appears on paper but is misconfigured in practice inflates perceived protection and understates likelihood.

Ongoing Monitoring Tab

Note: The Ongoing Monitoring tab is the highest-value integration target in the ITSRM solution. It is the default tab displayed when an information system is active and under assessment, making it the primary view for security and GRC teams tracking system health over time.

The Ongoing Monitoring tab aggregates real-time and historical data from external tools to give administrators and risk owners a continuous view of system health. Common data types surfaced here include:

Vulnerability metrics such as the number of critical or high vulnerabilities detected on a system over a rolling period, sourced from a vulnerability scanner.
Security events and alerts counts or metrics from a SIEM tool, showing incidents or anomalies associated with the system.
Control effectiveness results from a CCM or configuration scanning tool, showing pass/fail status on key controls.
Remediation ticket status from a ticketing tool, showing open issues tied to the system and their aging.
These data points are displayed as key risk indicators (KRIs), which can be tracked against thresholds and trended over time. This gives risk owners a meaningful signal about whether system risk is improving, stable, or deteriorating — without requiring a full reassessment.

Applications and Devices Repositories

Archer ITSRM maintains repositories for Applications and Devices that are associated with information systems. These repositories are strong candidates for integration with a Configuration Management Database (CMDB).

A CMDB integration allows you to populate these repositories automatically from the authoritative source of record for your technology assets. This ensures that the applications and devices linked to each information system reflect what is actually deployed, rather than relying on manually maintained records. Key fields to consider pulling in include asset classification, owner, environment, technology stack, and last-seen or last-updated timestamps.

Dashboards and Reporting

Archer ITSRM includes dashboards that provide leadership and risk teams with a consolidated view across information systems. Integration data enriches these dashboards by surfacing metrics from external tools alongside the risk assessments and control data already in Archer.

Example dashboard enhancements enabled by integrations include:

A heat map of information systems by vulnerability severity, combining the system’s criticality from Archer with live vulnerability data from a scanner.
A trend line showing the total number of open high-severity vulnerabilities across all systems over the past 90 days.
An aggregated view of open remediation tickets by system, helping risk teams understand where backlog is accumulating.
A summary of SIEM alerts by information system, highlighting which systems are generating the most security events.

Common Integration Use Cases

The following table outlines the most common integration use cases for ITSRM, the typical source system, the target location in Archer, and the primary benefit.

Use Case	Typical Source	Target in Archer	Primary Benefit
Vulnerability Metrics for Ongoing Monitoring	Vulnerability scanner (e.g., Tenable, Qualys, Rapid7)	Ongoing Monitoring tab on Information System; dashboards	Real-time KRIs tracking vulnerability counts by severity over time
Security Events for Ongoing Monitoring	SIEM (e.g., Splunk, Microsoft Sentinel, IBM QRadar)	Ongoing Monitoring tab on Information System	Provides a summary count of security events by period to indicate whether system activity warrants a risk reassessment.
Continuous Control Monitoring / Configuration Scanning	CCM or configuration tool (e.g., Cypago, Rapid7 InsightVM, AWS Config, Tanium)	Ongoing Monitoring tab; control records; likelihood scoring	Validates that controls are functioning, reducing likelihood score inflation
Ticketing and Remediation Tracking	Ticketing system (e.g., ServiceNow, Jira)	Ongoing Monitoring tab; Information System record	Tracks open issues tied to the system and aging of remediation activity
Asset and CMDB Synchronization	CMDB (e.g., ServiceNow CMDB, Ivanti, BMC Helix)	Applications and Devices repositories	Keeps asset inventory current without manual data entry
Threat Intelligence	Threat intel feed (e.g., MISP, Recorded Future, commercial feeds)	Threat records; likelihood scoring on Information System	Informs assessors of active threats relevant to the system’s technology stack

Integration Best Practices

Integrations that are planned carefully before implementation are significantly easier to maintain and extend. The following steps represent the recommended path for introducing integration data into ITSRM.

Create an On-Demand Application (ODA). An ODA is a blank Archer application that you configure from scratch to hold data from a specific source system. Create a dedicated ODA for each integration source — for example, one ODA for vulnerability metrics and a separate ODA for SIEM event metrics. Note that ODAs are a licensed component; work with your Archer account representative to confirm how many are available in your contract before planning your integration architecture.
Define your fields. Before building the integration, map out every field you intend to bring in from the source system and create corresponding fields in the ODA. This creates a clean data schema in Archer and ensures the integration has defined placeholders to populate. Include fields for system identifiers, timestamps, severity or category classifications, and any other attributes needed for filtering or reporting. Based on the data you want, this could also reflect timestamps and metrics, like a count or sum or vulnerability information.
Create cross-reference fields. Add cross-reference fields to the ODA that link records to the relevant Information System, Application, and/or Device records in Archer. This is what allows data in the ODA to surface on the Ongoing Monitoring tab and in system-specific dashboards.
Build the integration. Using the integration method appropriate for your source system (see Following Section), configure the data flow to pull records from the source and populate the ODA. Use a unique identifier to properly tie it to the appropriate assets, whether it be tied to an application, device, or directly to the information system.Test with a representative sample of data before enabling for production use.
Update dashboards. Once integration data is flowing into the ODA, configure Archer dashboards to surface that data at the portfolio level. Add charts, metrics, and trend views that reflect the new data source alongside existing risk data.
Update the Information System layout. Add the ODA data to the Information System record layout so that risk owners and assessors can see it in context. In some cases, you may need to roll up information from the applications and devices, if that is where the ODAs have been linked. For most integrations, this means adding a related records panel or key metric display on the Ongoing Monitoring tab, which is the default view for active systems under assessment.

Tip: It is recommended to document the field mapping between your source system and the Archer ODA as part of your integration design artifacts. This makes troubleshooting, upgrades, and handoffs to other administrators significantly easier.

Integration Methods

Archer supports several methods for integrating external data. The right method depends on the technical capabilities of your source system, your team’s skill set, and the frequency and volume of data transfer required.

APIs

Archer exposes a comprehensive set of REST APIs that allow external systems to read from and write to Archer applications programmatically. APIs are the most flexible integration method and support real-time or near-real-time data flows.

Archer’s API documentation is available on the Archer help site. The core REST API documentation can be found at:

Archer REST API Reference - https://help.archerirm.cloud/api_2026_02/content/api/archer_apis.htm

For organizations on Archer SaaS, additional next-generation APIs are available. Access instructions for these APIs are available at:

Next-Generation API Access (SaaS) - https://help.archerirm.cloud/api_2026_02/content/api/ngrx_apis.htm

Note: API integrations require an API-capable intermediary (such as a middleware platform, iPaaS tool, or custom application) to handle authentication, data transformation, and scheduling. This method is best suited for teams with development resources or an existing integration platform.

Data Feeds

Archer’s Data Feed Manager provides two options for pulling data from external sources on a scheduled basis. Data feeds are configured through a wizard interface in Archer and do not require custom application development for many common use cases.

SFTP / CSV Data Feed

This feed type allows Archer to retrieve a CSV file from a secure FTP server on a defined schedule. It is well-suited for source systems that can export data to a flat file format. Archer’s mapping wizard allows you to map columns in the CSV directly to fields in the target ODA without writing code. This is often the fastest path to getting data into Archer for teams without developer resources.

The source system must support scheduled exports to an SFTP server.
CSV column names do not need to match Archer field names — the mapping wizard handles the translation.
Scheduled execution frequency can be configured based on how often the source data changes.

JavaScript Transporter Data Feed

The JavaScript Transporter allows you to write a Node.js script that retrieves data from an external API or system and transforms it before loading it into Archer. This method is appropriate when the source system does not support file exports or when transformation logic is too complex for a simple CSV mapping.

Requires Node.js scripting skills.
Supports connections to REST APIs, databases, and other structured sources.
Transformation logic (filtering, mapping, normalization) is handled within the script, providing maximum flexibility.

One-Time Data Import

For initial data loads or occasional bulk updates, Archer’s Data Importer provides a no-code path to loading data from a file. This method is not suitable for ongoing automated integrations but is useful for initial population of an ODA or for loading historical data when first configuring an integration.

Accepts CSV format.
No coding required as the importer includes a field mapping interface.
Appropriate for one-time loads only; does not support scheduling or automation.

Note: If you are setting up an ongoing integration, use a Data Feed rather than the Data Importer. The Data Importer is intended for initial population or ad hoc loads, not for keeping data current over time.

Quick Reference: Choosing an Integration Method

Use the following table to identify the most appropriate integration method based on your requirements.

Requirement	REST API	SFTP / CSV Feed	JS Transporter	Data Importer
Real-time or near-real-time updates	Y	Y	Y	N
Scheduled / recurring loads	Y	Y	Y	N
One-time or ad hoc loads	Y	N	N	Y
No coding required	N	Y	N	Y
Complex transformation needed	Y	N	Y	N

Additional Resources

The following resources provide additional detail on the topics covered in this guide.

Archer REST API Reference – https://help.archerirm.cloud/api_2026_02/content/api/archer_apis.htm
Next-Generation API Access (SaaS) – https://help.archerirm.cloud/api_2026_02/content/api/ngrx_apis.htm
Archer ITSRM User Guide – Available on the Archer help site and Archer Community.