Practice Free CISA Exam Online Questions
Question #181
Which of the following would be of GREATEST concern when reviewing an organization’s security information and event management (SIEM) solution?
- A . SIEM reporting is customized.
- B . SIEM configuration is reviewed annually
- C . The SIEM is decentralized.
- D . SIEM reporting is ad hoc.
Correct Answer: C
C
Explanation:
The greatest concern that the IS auditor should have when reviewing an organization’s security information and event management (SIEM) solution is that the SIEM is decentralized. This is because a decentralized SIEM can pose challenges for collecting, correlating, analyzing and reporting on security events and incidents from multiple sources and locations. A decentralized SIEM can also increase the complexity and cost of maintaining and updating the SIEM components, as well as the risk of inconsistent or incomplete security monitoring and response. The IS auditor should recommend that the organization adopts a centralized or hybrid SIEM architecture that can provide a holistic and integrated view of the security posture and activities across the organization. The other findings are not as concerning as a decentralized SIEM, because they can be addressed by implementing best practices and standards for SIEM reporting and configuration.
References: CISA Review Manual (Digital Version)1, Chapter 5, Section 5.2.4
C
Explanation:
The greatest concern that the IS auditor should have when reviewing an organization’s security information and event management (SIEM) solution is that the SIEM is decentralized. This is because a decentralized SIEM can pose challenges for collecting, correlating, analyzing and reporting on security events and incidents from multiple sources and locations. A decentralized SIEM can also increase the complexity and cost of maintaining and updating the SIEM components, as well as the risk of inconsistent or incomplete security monitoring and response. The IS auditor should recommend that the organization adopts a centralized or hybrid SIEM architecture that can provide a holistic and integrated view of the security posture and activities across the organization. The other findings are not as concerning as a decentralized SIEM, because they can be addressed by implementing best practices and standards for SIEM reporting and configuration.
References: CISA Review Manual (Digital Version)1, Chapter 5, Section 5.2.4
Question #182
Which of the following provides re BEST evidence that outsourced provider services are being properly managed?
- A . Adequate action is taken for noncompilance with the service level agreement (SLA).
- B . The service level agreement (SLA) includes penalties tor non-performance.
- C . Internal performance standards align with corporate strategy.
- D . The vendor provides historical data to demonstrate its performance.
Correct Answer: A
Question #183
An IT governance body wants to determine whether IT service delivery is based on consistently effective processes.
Which of the following is the BEST approach?
- A . Evaluate key performance indicators (KPIs).
- B . Conduct a gap analysis.
- C . Develop a maturity model.
- D . Implement a control self-assessment (CSA).
Correct Answer: C
Question #184
During a security audit, an IS auditor is tasked with reviewing log entries obtained from an enterprise intrusion prevention system (IPS).
Which type of risk would be associated with the potential for the auditor to miss a sequence of logged events that could indicate an error in the IPS configuration?
- A . Sampling risk
- B . Detection risk
- C . Control risk
- D . Inherent risk
Correct Answer: B
B
Explanation:
The type of risk associated with the potential for the auditor to miss a sequence of logged events that could indicate an error in the IPS configuration is detection risk. Detection risk is the risk that the auditor’s procedures will not detect a material misstatement or error that exists in an assertion or a control. Detection risk can be affected by factors such as the nature, timing, and extent of the audit procedures, the quality and sufficiency of the audit evidence, and the auditor’s professional judgment and competence. Detection risk can be reduced by applying appropriate audit techniques, such as sampling, testing, observation, inquiry, and analysis.
References:
CISA Review Manual (Digital Version)
CISA Questions, Answers & Explanations Database
B
Explanation:
The type of risk associated with the potential for the auditor to miss a sequence of logged events that could indicate an error in the IPS configuration is detection risk. Detection risk is the risk that the auditor’s procedures will not detect a material misstatement or error that exists in an assertion or a control. Detection risk can be affected by factors such as the nature, timing, and extent of the audit procedures, the quality and sufficiency of the audit evidence, and the auditor’s professional judgment and competence. Detection risk can be reduced by applying appropriate audit techniques, such as sampling, testing, observation, inquiry, and analysis.
References:
CISA Review Manual (Digital Version)
CISA Questions, Answers & Explanations Database
Question #185
An IS auditor is reviewing an organization’s system development life cycle (SDLC).
Which of the following MUST be included in the review?
- A . Ownership of the system quality management plan
- B . Utilization of standards in the system development processes and procedures
- C . Validation that system development processes adhere to quality standards
- D . Definition of quality attributes to be associated with the system
Correct Answer: B
Question #186
Which of the following conditions would be of MOST concern to an IS auditor assessing the risk of a successful brute force attack against encrypted data at test?
- A . Short key length
- B . Random key generation
- C . Use of symmetric encryption
- D . Use of asymmetric encryption
Correct Answer: A
A
Explanation:
The condition that would be of most concern to an IS auditor assessing the risk of a successful brute force attack against encrypted data at rest is short key length. A brute force attack is a method of breaking encryption by trying all possible combinations of keys until finding the correct one. The shorter the key length, the easier it is for an attacker to guess or crack the encryption. Random key generation, use of symmetric encryption, and use of asymmetric encryption are not conditions that would increase the risk of a successful brute force attack. In fact, random key generation can enhance security by preventing predictable patterns in key selection. Symmetric encryption and asymmetric encryption are different types of encryption that have their own advantages and disadvantages, but neither is inherently more vulnerable to brute force attacks than the other.
References: CISA Review Manual (Digital Version): Chapter 5 – Information Systems Operations and Business Resilience
A
Explanation:
The condition that would be of most concern to an IS auditor assessing the risk of a successful brute force attack against encrypted data at rest is short key length. A brute force attack is a method of breaking encryption by trying all possible combinations of keys until finding the correct one. The shorter the key length, the easier it is for an attacker to guess or crack the encryption. Random key generation, use of symmetric encryption, and use of asymmetric encryption are not conditions that would increase the risk of a successful brute force attack. In fact, random key generation can enhance security by preventing predictable patterns in key selection. Symmetric encryption and asymmetric encryption are different types of encryption that have their own advantages and disadvantages, but neither is inherently more vulnerable to brute force attacks than the other.
References: CISA Review Manual (Digital Version): Chapter 5 – Information Systems Operations and Business Resilience
Question #187
Which of the following is MOST likely to be a project deliverable of an agile software development methodology?
- A . Strictly managed software requirements baselines
- B . Extensive project documentation
- C . Automated software programming routines
- D . Rapidly created working prototypes
Correct Answer: D
D
Explanation:
A project deliverable is a tangible or intangible product or service that is produced as a result of a project and delivered to the customer or stakeholder. A project deliverable can be either an intermediate deliverable that is part of the project process or a final deliverable that is the outcome of the project.
An agile software development methodology is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement. Teams follow a cycle of planning, executing, and evaluating. Agile software development methodologies value working software over comprehensive documentation and respond to change over following a plan.
Rapidly created working prototypes are most likely to be a project deliverable of an agile software development methodology because they:
Provide early and frequent feedback from customers and stakeholders on the functionality and usability of the software product
Allow for rapid validation and verification of the software requirements and design
Enable continuous improvement and adaptation of the software product based on changing customer needs and expectations
Reduce the risk of delivering a software product that does not meet customer needs or expectations
Increase customer satisfaction and trust by delivering working software products frequently and consistently
Some examples of agile software development methodologies that use rapidly created working prototypes as project deliverables are:
Scrum – a framework that organizes the work into fixed-length sprints (usually 2-4 weeks) and delivers potentially shippable increments of the software product at the end of each sprint1
Extreme Programming (XP) – a methodology that focuses on delivering high-quality software products through practices such as test-driven development, pair programming, continuous integration, and frequent releases2
Rapid Application Development (RAD) – a methodology that emphasizes rapid prototyping and user involvement throughout the software development process3
The other options are not likely to be project deliverables of an agile software development methodology.
Strictly managed software requirements baselines are not likely to be project deliverables of an agile software development methodology. A software requirements baseline is a set of agreed-upon and approved software requirements that serve as the basis for the software design, development, testing, and delivery. A strictly managed software requirements baseline is a software requirements baseline that is controlled and changed only through a formal change management process. Strictly managed software requirements baselines are more suitable for traditional or waterfall software development methodologies that follow a linear and sequential process of defining, designing, developing, testing, and delivering software products. Strictly managed software requirements baselines are not compatible with agile software development methodologies that embrace change and flexibility in the software requirements based on customer feedback and evolving needs.
Extensive project documentation is not likely to be project deliverables of an agile software development methodology. Project documentation is any written or electronic information that describes or records the activities, processes, results, or decisions of a project. Extensive project documentation is project documentation that covers every aspect of the project in detail and requires significant time and effort to produce and maintain. Extensive project documentation is more suitable for traditional or waterfall software development methodologies that rely on comprehensive documentation to communicate and document the project scope, requirements, design, testing, and delivery. Extensive project documentation is not compatible with agile software development methodologies that value working software over comprehensive documentation and use minimal documentation to support the communication and collaboration among the project team members.
Automated software programming routines are not likely to be project deliverables of an agile software development methodology. Automated software programming routines are programs or scripts that perform repetitive or complex tasks in the software development process without human intervention. Automated software programming routines can improve the efficiency, quality, and consistency of the software development process by reducing human errors, saving time, and enforcing standards. Automated software programming routines can be used in any software development methodology, but they are not specific to agile software development methodologies. Automated software programming routines are not considered as project deliverables because they are not part of the final product that is delivered to the customer.
D
Explanation:
A project deliverable is a tangible or intangible product or service that is produced as a result of a project and delivered to the customer or stakeholder. A project deliverable can be either an intermediate deliverable that is part of the project process or a final deliverable that is the outcome of the project.
An agile software development methodology is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement. Teams follow a cycle of planning, executing, and evaluating. Agile software development methodologies value working software over comprehensive documentation and respond to change over following a plan.
Rapidly created working prototypes are most likely to be a project deliverable of an agile software development methodology because they:
Provide early and frequent feedback from customers and stakeholders on the functionality and usability of the software product
Allow for rapid validation and verification of the software requirements and design
Enable continuous improvement and adaptation of the software product based on changing customer needs and expectations
Reduce the risk of delivering a software product that does not meet customer needs or expectations
Increase customer satisfaction and trust by delivering working software products frequently and consistently
Some examples of agile software development methodologies that use rapidly created working prototypes as project deliverables are:
Scrum – a framework that organizes the work into fixed-length sprints (usually 2-4 weeks) and delivers potentially shippable increments of the software product at the end of each sprint1
Extreme Programming (XP) – a methodology that focuses on delivering high-quality software products through practices such as test-driven development, pair programming, continuous integration, and frequent releases2
Rapid Application Development (RAD) – a methodology that emphasizes rapid prototyping and user involvement throughout the software development process3
The other options are not likely to be project deliverables of an agile software development methodology.
Strictly managed software requirements baselines are not likely to be project deliverables of an agile software development methodology. A software requirements baseline is a set of agreed-upon and approved software requirements that serve as the basis for the software design, development, testing, and delivery. A strictly managed software requirements baseline is a software requirements baseline that is controlled and changed only through a formal change management process. Strictly managed software requirements baselines are more suitable for traditional or waterfall software development methodologies that follow a linear and sequential process of defining, designing, developing, testing, and delivering software products. Strictly managed software requirements baselines are not compatible with agile software development methodologies that embrace change and flexibility in the software requirements based on customer feedback and evolving needs.
Extensive project documentation is not likely to be project deliverables of an agile software development methodology. Project documentation is any written or electronic information that describes or records the activities, processes, results, or decisions of a project. Extensive project documentation is project documentation that covers every aspect of the project in detail and requires significant time and effort to produce and maintain. Extensive project documentation is more suitable for traditional or waterfall software development methodologies that rely on comprehensive documentation to communicate and document the project scope, requirements, design, testing, and delivery. Extensive project documentation is not compatible with agile software development methodologies that value working software over comprehensive documentation and use minimal documentation to support the communication and collaboration among the project team members.
Automated software programming routines are not likely to be project deliverables of an agile software development methodology. Automated software programming routines are programs or scripts that perform repetitive or complex tasks in the software development process without human intervention. Automated software programming routines can improve the efficiency, quality, and consistency of the software development process by reducing human errors, saving time, and enforcing standards. Automated software programming routines can be used in any software development methodology, but they are not specific to agile software development methodologies. Automated software programming routines are not considered as project deliverables because they are not part of the final product that is delivered to the customer.
Question #188
Which of the following is MOST important during software license audits?
- A . Judgmental sampling
- B . Substantive testing
- C . Compliance testing
- D . Stop-or-go sampling
Correct Answer: B
B
Explanation:
Substantive testing is the most important type of testing during software license audits, as it provides evidence of the accuracy and completeness of the software inventory and licensing records. Substantive testing involves examining transactions, balances, and other data to verify their validity, existence, accuracy, and valuation. Compliance testing, on the other hand, is more focused on assessing the adequacy and effectiveness of internal controls over software licensing, such as policies, procedures, and monitoring mechanisms. Compliance testing alone cannot provide sufficient assurance that the software license audit objectives are met, as it does not verify the actual software usage and compliance status. Judgmental sampling and stop-or-go sampling are methods of selecting samples for testing, not types of testing themselves. *References: According to the ISACA IT Audit and Assurance Standards, Guidelines and Tools and Techniques for IS Audit and Assurance Professionals, section 1206 Testing, “The IS audit and assurance professional should perform sufficient testing to obtain sufficient appropriate evidence to support conclusions reached.” 1 The section also defines substantive testing as “testing performed to obtain audit evidence to detect material misstatements in transactions or balances” and compliance testing as “testing performed to obtain audit evidence on the operating effectiveness of controls.” 1 According to the ISACA IT Audit and Assurance Guideline G15 Software License Management, “The objective of a software license audit is to provide management with an independent assessment relating to compliance with software license agreements.” 2 The guideline also states that “substantive tests should be performed on a sample basis to verify that all software installed on devices within scope has been appropriately licensed.” 2
B
Explanation:
Substantive testing is the most important type of testing during software license audits, as it provides evidence of the accuracy and completeness of the software inventory and licensing records. Substantive testing involves examining transactions, balances, and other data to verify their validity, existence, accuracy, and valuation. Compliance testing, on the other hand, is more focused on assessing the adequacy and effectiveness of internal controls over software licensing, such as policies, procedures, and monitoring mechanisms. Compliance testing alone cannot provide sufficient assurance that the software license audit objectives are met, as it does not verify the actual software usage and compliance status. Judgmental sampling and stop-or-go sampling are methods of selecting samples for testing, not types of testing themselves. *References: According to the ISACA IT Audit and Assurance Standards, Guidelines and Tools and Techniques for IS Audit and Assurance Professionals, section 1206 Testing, “The IS audit and assurance professional should perform sufficient testing to obtain sufficient appropriate evidence to support conclusions reached.” 1 The section also defines substantive testing as “testing performed to obtain audit evidence to detect material misstatements in transactions or balances” and compliance testing as “testing performed to obtain audit evidence on the operating effectiveness of controls.” 1 According to the ISACA IT Audit and Assurance Guideline G15 Software License Management, “The objective of a software license audit is to provide management with an independent assessment relating to compliance with software license agreements.” 2 The guideline also states that “substantive tests should be performed on a sample basis to verify that all software installed on devices within scope has been appropriately licensed.” 2
Question #189
Which of the following features would BEST address risk associated with data at rest when evaluating a data loss prevention (DLP) solution?
- A . Printing of scan files
- B . File movement detection
- C . Enforcement of access policies
- D . Storage-scanning technology
Correct Answer: D
Question #190
An IS auditor evaluating the change management process must select a sample from the change log.
What is the BEST way to the auditor to confirm the change log is complete?
- A . Interview change management personnel about completeness.
- B . Take an item from the log and trace it back to the system.
- C . Obtain management attestation of completeness.
- D . Take the last change from the system and trace it back to the log.
Correct Answer: D
D
Explanation:
The answer D is correct because the best way for the auditor to confirm the change log is complete is to take the last change from the system and trace it back to the log. A change log is a record of all the changes that have been made to a system, such as software updates, bug fixes, configuration modifications, etc. A change log should contain information such as the date and time of the change, the description and purpose of the change, the person or service who made the change, and the approval status of the change. A complete change log helps to ensure that the system is secure, reliable, and compliant with the relevant standards and regulations.
An IS auditor evaluating the change management process must select a sample from the change log to verify that the changes are properly authorized, documented, tested, and implemented. However, before selecting a sample, the auditor must ensure that the change log is complete and accurate, meaning that it contains all the changes that have been made to the system and that there are no missing, duplicated, or falsified entries. To do this, the auditor can use a technique called backward tracing, which involves taking the last change from the system and tracing it back to the log. This way, the auditor can check if the change is recorded in the log with all the relevant details and if there are any gaps or inconsistencies in the log. If the last change from the system is not found in the log or does not match with the log entry, it indicates that the change log is incomplete or inaccurate.
The other options are not as good as option
D. Interviewing change management personnel about completeness (option A) is not a reliable way to confirm the change log is complete because it relies on subjective opinions and self-reported information, which may not be truthful or accurate. Taking an item from the log and tracing it back to the system (option B) is a technique called forward tracing, which can be used to verify that a specific change in the log has been implemented in the system. However, this technique does not confirm that all changes in the system are recorded in the log. Obtaining management attestation of completeness (option C) is not a sufficient way to confirm the change log is complete because it does not provide any evidence or verification of completeness. Management attestation may also be biased or influenced by conflicts of interest.
References:
IS Audit Basics: Auditing Data Privacy
Audit Logging: What It Is & How It Works | Datadog
Change Management for SOC: Risks, Controls, Audits, Guidance
Turn auditing on or off | Microsoft Learn
#118 | ITGC- System Change (Audit) Log Review – A2Q2
D
Explanation:
The answer D is correct because the best way for the auditor to confirm the change log is complete is to take the last change from the system and trace it back to the log. A change log is a record of all the changes that have been made to a system, such as software updates, bug fixes, configuration modifications, etc. A change log should contain information such as the date and time of the change, the description and purpose of the change, the person or service who made the change, and the approval status of the change. A complete change log helps to ensure that the system is secure, reliable, and compliant with the relevant standards and regulations.
An IS auditor evaluating the change management process must select a sample from the change log to verify that the changes are properly authorized, documented, tested, and implemented. However, before selecting a sample, the auditor must ensure that the change log is complete and accurate, meaning that it contains all the changes that have been made to the system and that there are no missing, duplicated, or falsified entries. To do this, the auditor can use a technique called backward tracing, which involves taking the last change from the system and tracing it back to the log. This way, the auditor can check if the change is recorded in the log with all the relevant details and if there are any gaps or inconsistencies in the log. If the last change from the system is not found in the log or does not match with the log entry, it indicates that the change log is incomplete or inaccurate.
The other options are not as good as option
D. Interviewing change management personnel about completeness (option A) is not a reliable way to confirm the change log is complete because it relies on subjective opinions and self-reported information, which may not be truthful or accurate. Taking an item from the log and tracing it back to the system (option B) is a technique called forward tracing, which can be used to verify that a specific change in the log has been implemented in the system. However, this technique does not confirm that all changes in the system are recorded in the log. Obtaining management attestation of completeness (option C) is not a sufficient way to confirm the change log is complete because it does not provide any evidence or verification of completeness. Management attestation may also be biased or influenced by conflicts of interest.
References:
IS Audit Basics: Auditing Data Privacy
Audit Logging: What It Is & How It Works | Datadog
Change Management for SOC: Risks, Controls, Audits, Guidance
Turn auditing on or off | Microsoft Learn
#118 | ITGC- System Change (Audit) Log Review – A2Q2