CCNA Information Systems Acquisition, Development, and Implementation Questions

Building custom software demands staffing, tooling and iterative testing that vendor licensing avoids, so delivery slips and budgets overrun — directly satisfying the stem's build-versus-buy constraint. The auditor should emphasise that no vendor solution met all requirements, meaning bespoke development absorbs the full cost and schedule risk internally.

Parallel changeover runs old and new systems simultaneously, requiring dual data entry and reconciliation. In a hospital, this can lead to discrepancies between the legacy EHR and the new system, potentially affecting patient care. The main risk is the complexity and cost of maintaining data integrity across both systems during the overlap period.

Throughput below the projected baseline means the system fails its defined performance objective, so the project did not deliver the agreed benefits. Budget compliance and delivery date are irrelevant to this finding; processing speed is a measurable acceptance criterion.

Normal changes follow the full assessment and authorisation path, so they require CAB approval before implementation. Standard changes are pre-authorised by a defined procedure, and emergency changes use a separate expedited route, typically with retrospective CAB review.

Embedding security requirements in user stories makes them estimable, testable and traceable within sprints. The auditor examines whether stories carry explicit security acceptance criteria, since this determines whether controls are actually built rather than deferred to post-release remediation.

A rollback plan provides a tested mechanism to revert to the prior stable state if deployment fails or introduces critical defects. This directly addresses the deployment phase's key risk — production disruption — by enabling rapid restoration of service, satisfying the stem's requirement for a key deployment control.

Each spiral cycle begins by analysing risks so that high-exposure items are addressed through prototyping and mitigation before major investment continues. This early resolution reduces the likelihood of costly rework or failure in later, more expensive iterations.

Incorrect mapping transfers values into wrong fields, corrupting balances, inventory and master data that downstream processes depend on. Because errors propagate silently and are costly to unwind post-cutover, mapping validation is a highest-risk migration concern.

Emergency changes bypass normal review, so the absence of post-implementation review leaves the change permanently unverified, with no confirmation it was authorised, tested, or documented. This defeats the control's compensating mechanism and represents the greatest change management concern.

The primary purpose of a post-implementation review is to determine if the system achieved its intended business objectives and benefits. This involves assessing user satisfaction, system performance, and alignment with business needs. Cost and schedule are inputs, but the core focus is on benefits realization and whether the system is fit for purpose.

The definition of done is agreed per sprint and should explicitly include security testing criteria. Auditing each sprint's definition of done confirms whether security activities are embedded iteratively, providing direct evidence rather than relying on retrospective claims or final-phase testing.

A credible schedule must reflect both logical dependencies and real resource availability. If the critical path is calculated without leveling against actual staff, the plan can show an impossibly short duration. The auditor should first confirm that zero-float tasks are correctly sequenced and that resourcing assumptions match the people actually assigned, because every later schedule claim depends on this foundation.

Building in-house gives the organization direct authority over the application's feature roadmap, letting it tailor functionality to unique business processes rather than adapting to a vendor's fixed release cycle. This satisfies the stem's decision factor: where differentiation or specialised requirements matter, custom development delivers feature control that COTS licensing cannot.

A rollback plan is the key deployment-phase control because it provides a tested mechanism to revert to the previous stable state if the release fails, directly satisfying the need to manage deployment risk and minimise disruption to production services. It addresses the stem's deployment-phase constraint, unlike design or post-implementation controls.

Data loss or corruption directly threatens the migration's integrity, since legacy-to-ERP transfers involve format conversions, field mapping and bulk loads where truncation, encoding faults or failed batches can silently corrupt records. This satisfies the stem's "most critical" constraint because corrupted financial data undermines the ERP's ledger accuracy and auditability irreversibly.

Referential integrity constraints prevent orphaned records and invalid relationships in the new database. If they are disabled during the load and not re-enabled and validated afterward, the database may contain inconsistent foreign key values that corrupt business logic and reporting. Confirming that constraints are active and that validation completed ensures the migrated data conforms to the target schema's relational rules.

On-time, on-budget delivery says nothing about value, so comparing realised benefits against the original business case tests whether the system actually delivered the expected outcomes — the gap the low satisfaction and defect backlog hint at.

Emergency changes bypass the normal change advisory board, so retrospective approval restores governance while documentation preserves the audit trail. This satisfies the IS auditor's requirement that emergency fixes still receive formal authorisation and traceability after implementation.

Pilot conversion involves implementing the new system for a small group of users, such as one department or location. This allows the organization to test the system in a real production environment, identify issues, and make adjustments before rolling out to the entire organization. This reduces the risk of widespread failure.

Functionality delivering competitive advantage is organisation-specific and unlikely to exist in a COTS product, so purchasing would force costly customisation or forfeit differentiation. Building internally lets the organisation own and tailor that capability, satisfying the strategic requirement that drives the build decision.

Iterative delivery produces working increments each cycle, so stakeholders review functioning software rather than documents, surfacing requirement defects while change remains cheap. This directly satisfies the stem's comparison against waterfall, whose single late validation phase defers feedback until rework is costly.

A post-implementation review compares actual outcomes against the business case and stated benefits, determining whether the system delivered its planned objectives. This addresses the primary governance objective rather than technical performance or user satisfaction alone.

In Agile development, security requirements must be integrated into the product backlog as user stories or acceptance criteria to be addressed during sprints. By reviewing these, the auditor can confirm that security is continuously validated, not deferred to the end. This approach aligns with the principle of building security in from the start, ensuring that each increment meets security expectations. The other options either postpone security testing or focus on documentation rather than actual implementation.

Audit rights contractually permit the buyer to examine the vendor's controls, records and compliance evidence, providing ongoing assurance over the outsourced system. This is the most important factor because it preserves the organisation's ability to verify security and regulatory compliance, satisfying the stem's vendor selection requirement.

Non-functional requirements define quality attributes such as performance, security, and availability. Without them, designers may make assumptions that lead to a system that fails to meet stakeholder expectations. These attributes are often costly to retrofit later. The auditor should ensure non-functional requirements are defined and approved before design begins to mitigate this risk.

Incorrect tax calculations breach statutory withholding and reporting obligations, producing wrong net pay and filing errors for affected employees. This is a data integrity failure in a legally mandated function, so it demands immediate correction ahead of cosmetic or efficiency issues.

Unresolved segregation of duties conflicts leave incompatible functions, such as creating a vendor and approving its payment, with one person. Unlike tuning or training issues, this is a live control failure that enables fraud or error, so it is the finding of greatest concern in a post-implementation review.

Mapping errors propagate corrupted or misaligned values into the new ERP, so migrated records may be incomplete or wrongly attributed. Because mapping defects are systemic, they affect entire data sets rather than isolated rows, undermining financial reporting and downstream processing long after go-live.

A documented rollback plan directly satisfies the emergency change constraint by enabling rapid restoration of the financial application if the change fails, minimising disruption to critical processing. Verifying it confirms the organisation can reverse unplanned modifications without extended downtime, which matters more than retrospective approvals when emergency changes bypass normal change management controls.

When one person can initiate, approve and record a transaction, no independent check exists, enabling fictitious vendors, duplicate payments or unauthorised adjustments to pass undetected. This is the classic fraud exposure that segregation of duties controls are designed to prevent.

The change advisory board's primary function is to assess each change's risk and impact, prioritise it against other changes, and authorise or reject it, satisfying the stem's focus on the change management process. Implementation and post-implementation review sit with other roles, not the CAB.

Documenting and approving security requirements during the requirements phase ensures controls are baselined before design and coding begin. This satisfies the stem's constraint that security requirements be formally documented and approved at the earliest phase, preventing costly retrofitting later.

The design phase translates requirements into technical specifications, so designing security controls here embeds confidentiality, integrity and availability measures into the solution before coding begins. Addressing security at design prevents costly retrofitting and satisfies the SDLC control objective of proactive risk mitigation.

Embedding SoD rules into role-based access controls means the ERP enforces conflicting-duty separation at design time, preventing toxic combinations such as creating a vendor and approving its payment. Configuring this during implementation satisfies the stem's concern before go-live.

Requirements are baselined and formally approved by the business owner before design begins, since later phases build directly on that frozen scope. Sign-off here authorises the project to proceed, whereas design and testing approvals occur within their own phases.

The sprint review inspects the completed increment against acceptance criteria, giving stakeholders tangible evidence of progress and a forum to raise issues. This transparency lets auditors verify that delivered functionality matches requirements rather than relying solely on documentation.

User acceptance testing is executed by end-users themselves, directly satisfying the stem's requirement that testing be performed by end-users. It validates the system against business needs and real-world workflows rather than technical specifications, confirming fitness for purpose before go-live. This distinguishes it from unit, integration and system testing, which developers or testers conduct.

Effectiveness depends on testers representing real users exercising genuine business workflows against representative data. Business testers with realistic data validate that the system meets actual operational needs, whereas IT staff or synthetic data would miss usability and process gaps.

A test plan evidences that the change was verified before release, confirming the requester identified how functionality and related controls would be validated. Without it, governance cannot demonstrate that the change works as intended or that regression risk was assessed prior to production deployment.

Documenting each emergency change with justification and reviewing it promptly afterwards confirms the control operated: the change was authorised retrospectively and assessed, rather than bypassing governance entirely, which is the strongest evidence of proper control.

Without traceability from requirements to configuration items, the team cannot quickly determine which customizations support which business needs or which vendor patches will affect them. During an upgrade, this gap forces costly discovery work and increases the chance of breaking critical functionality. The greatest risk is therefore an inability to assess upgrade impact, which can delay patching and introduce production outages.

Unsigned requirements leave scope unbaselined, so later changes cascade through design, build and test with no approved reference point. In waterfall, defects introduced at requirements cost most to correct, and the missing sign-off removes the control that would otherwise catch stakeholder misalignment before construction begins.

Emergency changes bypassing subsequent CAB review leave the most critical control gap: changes reach production without retrospective scrutiny, risking undocumented, untested modifications to a financial application. Other findings are less severe because normal changes still receive approval before deployment.

Justification records the business or technical reason the change is needed, letting the Change Advisory Board weigh benefit against risk and cost. Without it, approvers cannot judge whether the change is warranted, so the document fails its decision-support purpose.

Passing only 60% of UAT cases means 40% of tested business scenarios failed, so the system may not satisfy requirements and users will adopt manual workarounds that undermine controls and reporting integrity. This is the most significant risk.

Security requirements must be captured alongside functional requirements so they are baselined and approved before design begins. Documenting them in the requirements phase lets the business owner formally accept them, preventing costly retrofitting of controls during coding or testing.

A SOC 2 report covers the vendor's controls against trust services criteria, giving the organisation independent assurance over security and processing integrity. It is obtained once and shared with many customers, avoiding the cost of exercising the contractual audit right.

Incomplete or inaccurate conversion transfers corrupt, missing or duplicated records into the ERP, directly undermining financial reporting, payroll accuracy and subsequent processing. This is the most significant migration risk because defects introduced silently during conversion are difficult to detect and costly to remediate once live.

Analysing risk at the start of every spiral iteration surfaces threats and uncertainties before significant design and coding effort is committed, so mitigation can be planned into the next loop. This early detection reduces the cost of rework compared with deferring risk assessment to later lifecycle phases.

MASVS verification requires a mix of automated and manual testing to cover all storage locations and data types. Static and dynamic analyses identify code-level and runtime issues, while manual review ensures that all sensitive data is stored securely. This comprehensive approach provides strong evidence of compliance with the standard's requirements.

The sprint review is where the team demonstrates completed user stories against their acceptance criteria with stakeholders present. This gives the auditor direct evidence of whether each story actually satisfies the defined criteria before it is accepted.

In RAD, documentation may be lighter, but critical design decisions and control specifications should still be documented to enable maintenance, audits, and compliance. The auditor should verify that essential documentation exists, even if it is not as extensive as in waterfall. This ensures the system remains auditable and maintainable without stifling the RAD approach.

Continuous automated monitoring detects toxic access combinations across the ERP as roles and users change, flagging conflicts that manual reviews miss. It provides detective coverage throughout implementation, when role design is still fluid and SoD conflicts are introduced.

Sprint reviews provide evidence that stakeholders inspect the increment each sprint, satisfying the need for continuous user acceptance in agile delivery. Unlike a single end-of-project sign-off, this recurring stakeholder validation demonstrates acceptance controls operate throughout development, directly addressing the stem's requirement for adequate user acceptance evidence.

Spiral development iterates through repeated risk analysis cycles, so an incomplete or superficial risk assessment undermines the model's core control. The auditor's primary focus is therefore whether each spiral iteration properly identifies, evaluates and mitigates risk before proceeding.

Iterative models deliver working increments in short cycles, allowing requirements to be revisited between iterations. Waterfall freezes requirements after the analysis phase, so late changes are costly; iteration directly satisfies the need to accommodate evolving requirements.

The most critical factor is whether the SOC 2 report's scope aligns with the services the organization will consume. If the report excludes relevant systems or processes, it cannot be relied upon to provide assurance over those areas. The auditor must verify that the controls tested are relevant to the organization's use of the vendor's services.

The root cause was a misunderstanding of tax law changes, which indicates that the requirements were not accurately captured or validated. Involving tax experts and business stakeholders would have ensured that the requirements reflected current tax laws. This is a critical control in the requirements phase. Without their input, the system was built on incorrect assumptions, leading to payroll errors. Thus, this is the most likely control weakness.

Reviewing code only after unit testing delays defect detection until later lifecycle stages, when remediation requires reworking tested components and dependent code. Defects found earlier during review are cheaper to fix, so this sequencing inflates rework cost and schedule risk.

Audit rights clauses let the organisation inspect the vendor's control environment, obtain evidence and enforce remediation, directly addressing the risk that the vendor's security controls are inadequate. Without this contractual leverage, assurance over a COTS ERP's hosted processing depends solely on the vendor's own reporting.

Performance criteria were defined in the business case, so the auditor must first compare measured transaction throughput against those agreed benchmarks. This establishes whether the shortfall is a genuine deviation before investigating root cause or recommending remediation.

A software escrow agreement ensures that source code and related materials are held by a third party and released to the customer if the vendor fails to meet obligations, such as going bankrupt. This allows the organization to maintain and modify the software independently, ensuring business continuity. It directly addresses the risk of vendor failure, making it the most important clause in this scenario.

Each iteration ends with a working increment that users evaluate, and their feedback shapes the next cycle's requirements and design. This continuous user involvement is a defining trait of iterative development, satisfying the stem's requirement for a characteristic of that model.

Security requirements, including authentication, authorization, encryption, and auditing, are often classified as non-functional. If they are not specified, developers may not implement them, leaving the system vulnerable to breaches. This is a critical risk because security is essential for protecting data and complying with regulations. Thus, this is a major consequence of missing non-functional requirements.

Low satisfaction despite budget compliance suggests functional shortfalls, so the auditor should test whether the system delivered the predefined user requirements. Unmet requirements directly explain user dissatisfaction and indicate the project missed its stated objectives.

The sprint review demonstrates the completed increment to stakeholders, exposing working functionality and the controls embedded in it. This gives the auditor direct evidence of control effectiveness for the current sprint, unlike planning or retrospective sessions.

An adverse SOC 2 opinion means the vendor's controls failed to meet trust services criteria, so the auditor should recommend evaluating compensating controls or selecting an alternative vendor. This directly addresses the assurance gap the adverse opinion creates for a critical system.

Segregation of duties is enforced through the application's role design and access control configuration. Reviewing role definitions, permission assignments, and conflicting role analysis provides direct evidence that incompatible duties cannot be performed by one user. This is the most appropriate source because it shows how the system actually restricts access, rather than relying on policy statements or user interviews that may not reflect the implemented controls.

Build decisions are justified when required functionality is unavailable commercially, since a COTS product cannot be modified to deliver it. This specialised-functionality gap is the decisive factor; cost, integration and support considerations matter but do not by themselves mandate building.

A prioritised product backlog containing security requirements ensures controls are scheduled and delivered within sprints rather than deferred indefinitely. This satisfies the agile payroll scenario by embedding security into iterative planning, giving the auditor evidence that compliance and data protection needs are tracked alongside functional features.

A fixed-price contract sets the total cost before work begins, so the buyer bears no risk of cost overruns, giving predictable budgeting. The seller absorbs overrun risk instead, which is why vendors often price such contracts higher.

Performance analysis isolates which component causes the 30% shortfall before any fix is chosen. Recommending tuning, hardware or redesign first would address symptoms without evidence; identifying bottlenecks satisfies the review's need for a root cause.

Formal UAT sign-off requires business users to validate the system against documented requirements before go-live, providing the definitive control that confirms business requirements are met. This satisfies the waterfall model's need for verification at the testing phase before implementation proceeds.

Threat modeling examines the proposed architecture, data flows and trust boundaries to identify threats before code exists, so design flaws can be remediated cheaply. This directly satisfies the stem's design-phase constraint, where controls are cheapest to embed and rework costs are lowest.

Without a tested rollback procedure, a failed upgrade could leave the system unrecoverable, breaching availability and change-management controls. Delaying deployment until rollback is created and tested ensures the approved change can be safely reversed, satisfying the auditor's requirement that changes remain recoverable before implementation proceeds.