Free CIS-SIR Practice Test

The ServiceNow Store is the official enterprise marketplace for applications and integrations built on the Now Platform. When a required integration is not available out-of-the-box, the Store is the designated next step to find solutions that have been vetted and certified by ServiceNow. These certified applications, developed by both ServiceNow and its technology partners, ensure quality, security, and compatibility with the platform. This process guarantees a level of trust and support that is not available through other means.

A. Building your own is a valid option for creating a custom integration, but it is not a method for finding an existing certified one.
B. The community page is a valuable resource for peer-to-peer support and advice, but it is not the official channel for obtaining certified applications.
C. ServiceNow Share is a repository for community-developed content. While useful, these solutions are typically not certified and are provided without official support.

1. ServiceNow Product Documentation: "The ServiceNow Store is an enterprise application marketplace for paid and free applications and integrations that are certified and built on the Now Platform." (ServiceNow Product Documentation, "ServiceNow Store," Tokyo release).

2. ServiceNow Developer Documentation: "The ServiceNow Store is the ServiceNow application marketplace. The Store allows ServiceNow partners and developers to sell, share, and install certified applications and integrations." (ServiceNow Developer Site, "Application Repository," Application Repository module).

3. ServiceNow Product Documentation: "Security Operations has a number of integrations with other security products. Many of these integrations are available from the ServiceNow Store." (ServiceNow Product Documentation, "Available Security Operations integrations," Tokyo release).

In the ServiceNow Security Incident Response (SIR) application, the Post Incident Review (PIR) process is designed to gather feedback from key participants. By default, the system automatically populates the 'Request Assessments' related list with any user who was assigned one or more response tasks during the lifecycle of the security incident. This automation ensures that individuals who were directly involved in executing the response plan are prompted to provide their assessment, which is crucial for identifying process improvements and lessons learned.

A. Any user that adds a worknote to the ticket: Adding a worknote does not automatically add a user to the assessment list. This action is too broad and could include users with only minor involvement.
B. The analyst assigned to the ticket: While the assigned analyst is a key stakeholder, the automatic rule is based on response task assignment, not the primary 'Assigned to' field of the incident.
D. The Affected User on the incident: The affected user is not automatically added to the assessment list by default, though they can be added manually if their perspective is needed for the review.

1. ServiceNow Product Documentation - Security Incident Response: On the "Request assessments for a post incident report" page, the documentation explicitly states: "When you click Request Assessments, questionnaires are sent to the users listed in the Request Assessments related list. By default, any user who is assigned a response task is automatically added to this list." (ServiceNow Doc: Washington D.C. Release, Security Incident Response, Document ID: f28096c193322200654771937a7a00b3, Section: Request assessments for a post incident report).

In ServiceNow Security Incident Response (SIR), the severity of an incident is dynamically calculated based on factors like business impact and priority. The business impact is directly derived from the value of the affected assets. The primary records used to represent these assets are Configuration Items (CIs) from the CMDB and the Business Services they support. When a security incident is created, it is linked to these affected CIs and/or Business Services, and their predefined criticality is used by the severity calculator to determine the overall incident severity.

C. Calculator Group: This is a configuration record within the SIR application that groups severity calculation rules; it is not a business or IT asset that can be affected by an incident.
D. Severity Calculator: This is a configuration record that defines the logic and matrix for calculating severity based on inputs like business impact; it is not an operational asset.

1. ServiceNow Product Documentation, "Severity calculation in Security Incident Response": "The severity of a security incident is determined by its business impact and priority... Business impact is the effect that a security incident has on your business. It's determined by the criticality of the affected asset or business service." This document explicitly names both asset (CI) and business service as inputs.

2. ServiceNow Product Documentation, "Associate CIs and assets to a security incident": "You can associate configuration items (CIs) and assets to a security incident to identify the business impact of a security incident... The Affected CIs related list shows the configuration items that are associated with the security incident." This confirms CIs are the primary affected asset type.

3. ServiceNow Product Documentation, "Security Incident Response impact analysis": "When a security incident is created, you can use the CMDB to identify the affected CIs and business services. You can then use the dependency map to determine the upstream and downstream impact of the security incident." This highlights that both CIs and Business Services are the key entities analyzed for impact.

In ServiceNow Security Incident Response (SIR), the Severity field is automatically calculated using a combination of the incident's Priority and its Business Impact. The Business Impact is a critical component that reflects the potential effect on business processes. This value is most often determined by the business value or criticality of the affected asset (Configuration Item - CI). For example, an incident affecting a mission-critical production database will have a much higher business impact, and therefore a higher severity, than one affecting a non-critical development server. This ensures that response efforts are correctly aligned with the potential harm to the organization.

A. The cost of the response to the security breach: Cost is a post-incident metric used for analysis and reporting; it does not determine the initial severity of the incident.
B. The impact, urgency and priority of the incident: This is incomplete. While Priority (which is derived from Impact and Urgency) is one input, this option omits the equally important Business Impact component.
C. The time taken to resolve the security incident: Resolution time is a performance metric (e.g., MTTR) measured after the fact, not an input for calculating the initial severity.

1. ServiceNow Product Documentation - Security incident severity calculation: "The severity of a security incident is determined by its business impact and priority... Business impact: The effect on business processes. This value is often determined by the business value of the affected asset." (ServiceNow Documentation for Washington DC release, Security Incident Response > Security incidents > Security incident severity calculation).

2. ServiceNow Now Learning - Security Incident Response (SIR) Fundamentals On Demand: In the "Security Incident Triage" module, the courseware explains that the Severity Rating is derived from a matrix using two inputs: Priority and Business Impact. It explicitly states that Business Impact is linked to the criticality of the affected Configuration Item (CI).

The snsi.admin (Security Admin) role is required to perform administrative and configuration tasks within the Security Incident Response (SIR) application. This includes configuring foundational elements like Territories and Skills, which are used by Advanced Work Assignment (AWA) to route security incidents to the appropriate analysts. This role contains all other snsi. roles and provides the necessary permissions to modify the application's behavior and settings, which is beyond the scope of user-level roles like Analyst or Manager.

A. Security Basic (snsi.basic): This role grants read-only access to SIR records and is the most fundamental user role, lacking any configuration capabilities.
B. Manager (snsi.manager): This role is for overseeing security incidents, managing teams, and reporting, but it does not include permissions for system-level configuration of features.
C. Security Analyst (snsi.analyst): This role is for users who actively investigate and resolve security incidents. It does not grant the privileges needed to configure application settings.

1. ServiceNow Product Documentation - Security Incident Response roles: The official documentation explicitly defines the snsi.admin role. It states, "Users with this role can administer the Security Incident Response application. This role contains all the roles in the Security Incident Response application." This administrative function inherently includes the configuration of application features. (ServiceNow, Security Incident Response roles, Doc ID: f281e399c33122002841b63b12d3ae6c).

2. ServiceNow Product Documentation - Configure skills for Security Incident Response: The procedure for configuring skills and other Advanced Work Assignment (AWA) features like territories requires administrative privileges to access modules like Skills Management and Assignment Rules. The snsi.admin role is the designated administrator for the SIR application, granting these permissions. (ServiceNow, Configure skills for Security Incident Response, Doc ID: 01148d825386101034c8ddeeff7b123d).

The EmailUserReportedPhishing script include is a core component of the User Reported Phishing feature within ServiceNow Security Incident Response. When a user forwards a suspicious email to a designated mailbox, the EmailUserReportedPhishing inbound action triggers this script. The script's primary function is to parse the forwarded email and create a new record in the User Reported Phishing Submissions table. The technical name for this table is snsiphishingemail. This record acts as the initial submission, which can then be analyzed, and if deemed malicious, escalated into a full security incident (snsiincident).

A. arsnsiphishingemail: The ar prefix typically denotes an archive table in ServiceNow, which is used for long-term storage of inactive records, not for creating new ones.
B. snsiincident: This is the main Security Incident table. While a phishing submission can be promoted to a security incident, the initial record is not created here.
C. snsiphishingemailheader: This table stores parsed email header data associated with a phishing submission, but it is not the primary table for the submission itself.

1. ServiceNow Product Documentation: In the "User Reported Phishing" feature overview

the process is explicitly described: "The User Reported Phishing inbound email action processes the email and creates a record in the User Reported Phishing Submission [snsiphishingemail] table."

Source: ServiceNow Product Documentation

"User Reported Phishing

" Washington DC Release.

2. ServiceNow Product Documentation: The configuration guide for the inbound action confirms the target table: "When an email is received by the inbound action

a record is created in the User Reported Phishing Submissions [snsiphishingemail] table."

Source: ServiceNow Product Documentation

"Configure the User Reported Phishing inbound email action

" Washington DC Release.

3. ServiceNow Developer Documentation: The table schema confirms the purpose of the snsiphishingemail table.

Source: ServiceNow Developer Site

Table name: snsiphishingemail

Label: "User Reported Phishing Submission".

The cornerstone of a successful ServiceNow implementation is a deep and thorough understanding of the customer's strategic goals and business objectives. This foundational step ensures that the platform's configuration, workflows, and integrations are purposefully designed to address specific business problems and deliver measurable value. Aligning the technical solution with desired business outcomes prevents scope creep, maximizes user adoption, and ensures the project delivers a return on investment by solving the right problems for the organization.

A. Selling the most expensive package is a commercial tactic, not an implementation principle, and may result in providing features the customer does not need.
B. Implementing all available features is inefficient, leads to unnecessary complexity, and ignores the specific, prioritized needs of the customer.
D. Building custom integrations is a tactical task performed to support business objectives, not the foundational key to overall project success.

1. ServiceNow Now Create Methodology: The official ServiceNow implementation methodology, Now Create, is built around achieving customer outcomes. The "Initiate" phase is dedicated to activities like "Define business case," "Define business outcomes," and "Define program," all of which center on understanding the customer's goals before any technical work begins. (Source: ServiceNow Now Create, "Initiate" Phase Task Descriptions).

2. ServiceNow Product Documentation - Planning Security Incident Response: The official documentation for implementing Security Incident Response explicitly states the importance of planning based on goals. It advises, "Before you begin to set up Security Incident Response, you should have a clear understanding of your goals for the implementation." This highlights that understanding objectives is the critical first step. (Source: ServiceNow Product Documentation, Quebec, "Plan your Security Incident Response implementation").

3. ServiceNow White Paper - The ServiceNow Implementation: A CIO’s Guide to Driving Real Results: This guide emphasizes a value-based approach, stating, "Start with your business objectives... Successful ServiceNow implementations begin not with the technology, but with a clear understanding of the business outcomes you want to achieve." (Source: ServiceNow White Paper WP0010-18, Page 3, "Start with your business objectives").

The Traffic Light Protocol (TLP) is a system for classifying sensitive information. TLP:AMBER is used when information requires sharing within an organization or with its clients on a need-to-know basis to take protective action. Its primary restriction is that it cannot be shared outside of the involved organizations because of the risk to privacy, reputation, or operations. This level appropriately balances the need for internal collaboration with the containment of sensitive data, which directly matches the scenario described in the question.

A. TLP:GREEN: This level permits sharing with partner organizations within a specific community or sector, which is a broader scope than the "organizations involved" described.
C. TLP:RED: This is too restrictive. It limits information to the direct recipients only ("eyes only") and prohibits any further sharing, even within their own organization.
D. TLP:WHITE: This level has no distribution limits and allows for public disclosure, which is contrary to the stated risk of sharing the information.

1. Forum of Incident Response and Security Teams (FIRST). Traffic Light Protocol (TLP) - FIRST Standards Definitions and Usage Guidance — Version 2.0. Section 3.3

"TLP:AMBER".

"Recipients may only share TLP:AMBER information with members of their own organization

and with clients or customers who need to know the information to protect themselves or prevent further harm

on a need-to-know basis."

2. ServiceNow Product Documentation. Security Incident Response > Security tags in Security Incident Response > Security tag sources for Security Incident Response.

The documentation outlines the use of the Traffic Light Protocol (TLP) as a predefined security tag source. The definition for the snsi.tlpamber tag aligns with the FIRST standard

indicating its use for limited disclosure restricted to participants' organizations.

The Security Operations Spoke is the official ServiceNow plugin that provides a collection of actions for use within Flow Designer. These actions are specifically designed to automate tasks across the Security Operations suite, including creating, updating, and managing security incidents, as well as interacting with observables and other related records. Activating this spoke makes the "Security Operations" category and its associated actions available in the Flow Designer interface for building automated security response workflows.

A. This plugin provides dashboards and key performance indicators for reporting, not automation actions for Flow Designer.
B. "Security Spoke" is a generic term and not the name of an official ServiceNow plugin for this purpose.
D. A dedicated "Security Incident Spoke" does not exist; its actions are consolidated within the Security Operations Spoke.

1. ServiceNow Product Documentation: "Security Operations Spoke". The documentation explicitly states, "The Security Operations Spoke provides actions to automate Security Incident Response, Vulnerability Response, and Threat Intelligence tasks." It lists actions such as Create Security Incident, Update Security Incident, and Add Observable to Security Incident. (ServiceNow Product Documentation, Washington DC Release, Document ID: flow-designer-sn-sec-cmn-spoke).

2. ServiceNow Store: The official listing for the "Security Operations Spoke" describes its purpose: "Provides a set of actions for Security Operations applications (Security Incident Response, Vulnerability Response, Threat Intelligence) to use in Flow Designer." (ServiceNow Store, App ID: snseccmnspoke).

In ServiceNow Security Incident Response (SIR), playbooks built using Flow Designer are made available for a specific security incident based on trigger conditions. A trigger initiates a flow (the playbook) when a record, such as a security incident, is created or updated and its field values match the conditions defined in that trigger. For example, a playbook for phishing can be configured with a trigger that runs only when a security incident's 'Category' is 'Phishing'. If the incident's data matches the trigger's conditions, the associated playbook is displayed and can be executed.

A. Actions are the individual steps or operations within a playbook, such as creating tasks or enriching data; they do not determine the playbook's initial visibility.
C. The term "Runbook" is generally associated with automated procedures but is not a specific property in Flow Designer that controls playbook association via triggers.
D. Service Criticality being 'High' is an example of a specific condition that could be used within a trigger, but it is not the underlying mechanism itself, which is the trigger.

1. ServiceNow Product Documentation - Playbooks for Security Incident Response: "You can configure a playbook to run based on conditions in the security incident. For example, you can configure a playbook to run when the incident category is Phishing and the priority is High." This directly links playbook availability to conditions on the incident record. (ServiceNow Docs: Security Incident Response > Playbooks for Security Incident Response > Use playbooks).

2. ServiceNow Product Documentation - Flow Designer triggers: "A trigger starts a flow when a record is created or updated, a schedule is met, or an application is called... For record-based triggers, specify a table and a set of filter conditions. When a record on the specified table is created or updated to match the filter conditions, the system runs the flow." This explains the fundamental mechanism. (ServiceNow Docs: Flow Designer > Triggers > Flow Designer triggers).