I85PREP
⌘ K
ISTQB CT-SEC study materials
ISTQB CT-SEC study resources

ISTQB CT-SEC practice questions

One question at a time. Build your ISTQB CT-SEC understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Security testing planning

Which document is the primary input when deriving the security test strategy for a new release, because it defines what the organization considers an acceptable level of risk?

  1. The test automation framework architecture document
  2. The functional requirements traceability matrix
  3. The performance benchmark baseline report
  4. The security policy and risk assessment results for the system Correct answer.

Explanation

Security test planning must be driven by the organization's security policy and by risk assessment outcomes, since together they define which assets matter and how much exposure is tolerable. Functional, automation, and performance artifacts inform other test types but do not state acceptable risk.

Question 2Security testing planning

During security test planning, what is the main purpose of defining an explicit scope boundary for the test effort?

  1. To guarantee that no defects remain in the tested system
  2. To identify which components, interfaces, and data are in and out of the security assessment Correct answer.
  3. To allow testers to skip risk analysis once the boundary is documented
  4. To replace the need for a threat model with a list of excluded items

Explanation

A scope boundary records which components, interfaces, environments, and data sets are covered and which are deliberately excluded, so that stakeholders understand residual exposure. It does not guarantee defect-free software, nor does it substitute for risk analysis or threat modeling.

Question 3Security testing planning

A team is planning security tests for a payment service and must decide how much effort to allocate. Which approach aligns best with risk-based security test planning?

  1. Prioritize modules by number of lines of code
  2. Distribute effort equally across all modules regardless of exposure
  3. Test only the modules with the newest source code
  4. Concentrate effort on components handling sensitive data and reachable from untrusted networks Correct answer.

Explanation

Risk-based planning allocates effort according to likelihood and impact, so assets that process sensitive data and are exposed to untrusted input attract the most testing. Equal distribution, code recency, and code size are poor proxies for security risk.

Question 4Security testing planning

Which element belongs in a security test plan but typically not in a functional test plan?

  1. The list of identified threat agents and abuse cases to be exercised Correct answer.
  2. Entry and exit criteria for test execution
  3. The schedule of regression test cycles
  4. The roles and responsibilities of the test team

Explanation

Security test plans characteristically enumerate threat agents, attack surface, and misuse or abuse cases that drive negative testing. Entry/exit criteria, schedules, and team roles are generic planning elements shared with functional test plans.

Question 5Security testing planning

An organization plans security testing for a system that processes regulated personal data. Which planning consideration most directly addresses legal and compliance obligations?

  1. Mapping required security controls and evidence to the applicable regulatory standard Correct answer.
  2. Reducing the test team size to lower cost
  3. Scheduling tests to run only after business hours
  4. Selecting a load-testing tool with the highest throughput

Explanation

Compliance-driven planning requires tracing each mandated control to the test activities and evidence that demonstrate it, so audit obligations are satisfied. Tool throughput, timing, and team size do not address regulatory requirements.

Question 6Security testing planning

What is the primary reason to define security test environment requirements early in planning?

  1. To eliminate the need for test data management
  2. To ensure realistic attack simulation without endangering production data or services Correct answer.
  3. To reduce the number of test cases that must be written
  4. To allow testers to bypass change management procedures

Explanation

Security tests often involve intrusive techniques such as injection or denial-of-service simulation, so the environment must be isolated and populated with safe data to avoid harm to production. Environment planning does not reduce test case counts, remove data management needs, or waive change control.

Question 7Security testing planning

Which metric best indicates the effectiveness of a planned security test effort rather than merely its activity level?

  1. Percentage of identified high-risk threats covered by at least one executed test Correct answer.
  2. Count of tools installed on the test workstations
  3. Total hours spent in the security test environment
  4. Number of test cases executed per tester per day

Explanation

Coverage of high-risk threats by executed tests measures whether the planned effort actually addresses the risks that matter. Execution rates, hours, and tool counts are activity indicators that say nothing about risk coverage.

Question 8Security testing planning

When planning security tests for a system built largely from third-party components, which planning action is most appropriate?

  1. Assume third-party code is secure because it is widely used
  2. Replace all third-party components before any testing begins
  3. Include verification of known vulnerabilities and patch levels for third-party components Correct answer.
  4. Exclude third-party components from the security test scope entirely

Explanation

Third-party components carry known vulnerability and patch-management risk, so planning should include checking component versions against vulnerability sources and confirming patching. Assuming safety, excluding them, or mandating wholesale replacement are not proportionate planning responses.

Question 9Security testing planning

Which activity best characterizes the planning of security testing within a shift-left approach?

  1. Assigning security testing exclusively to an external audit firm
  2. Running security tests only when a breach has occurred
  3. Integrating lightweight security checks into early development stages and pipelines Correct answer.
  4. Deferring all security verification to a penetration test before release

Explanation

Shift-left planning moves security verification earlier, embedding checks such as static analysis and abuse-case review into development and continuous integration. Deferring to a single late penetration test, outsourcing exclusively, or reacting only to incidents contradicts the shift-left principle.

Question 10Security testing planning

A security test plan states that testing will stop when the number of critical findings reaches zero. Which planning weakness does this exit criterion exhibit?

  1. It requires too much involvement from business stakeholders
  2. It is too difficult to measure objectively
  3. It duplicates the entry criteria for the test cycle
  4. It relies on a criterion that can be gamed and ignores residual risk and coverage Correct answer.

Explanation

Counting only critical findings encourages reclassification and says nothing about untested areas or accepted residual risk. A sound exit criterion combines severity thresholds with coverage of planned threat scenarios and documented risk acceptance.

Question 11Security testing planning

Which factor most strongly justifies increasing the planned depth of security testing for a particular feature?

  1. The feature has extensive unit test coverage
  2. The feature was developed by a senior engineer
  3. The feature has a large user interface with many screens
  4. The feature is reachable by anonymous internet users and handles authentication decisions Correct answer.

Explanation

Exposure to anonymous users combined with security-critical logic such as authentication raises both likelihood and impact of exploitation, justifying deeper testing. Developer seniority, existing unit coverage, and interface size are weak indicators of security risk.

Question 12Security testing planning

In security test planning, what distinguishes an abuse case from a normal use case?

  1. An abuse case documents a defect found during functional testing
  2. An abuse case is a use case that has been deferred to a later release
  3. An abuse case describes how an adversary attempts to misuse the system to achieve an harmful goal Correct answer.
  4. An abuse case describes intended user behavior with expected results

Explanation

Abuse cases model adversarial intent, capturing how a threat agent could misuse functionality to violate a security objective, and they drive negative security tests. Normal use cases describe legitimate behavior, not adversarial goals.

Question 13Security testing planning

Which planning artifact best communicates to non-technical stakeholders why certain security tests are prioritized?

  1. A list of source code files changed in the last sprint
  2. A risk register linking assets, threats, and planned test activities Correct answer.
  3. A raw log of scanner output
  4. A network diagram without annotations

Explanation

A risk register ties business assets to identified threats and to the test activities that address them, making prioritization rationale explicit and understandable. Raw scanner logs, change lists, and unannotated diagrams lack the linking of risk to planned action.

Question 14Security testing planning

When planning security testing for an application programming interface consumed by partners, which test focus is most specific to that context?

  1. Verifying the visual layout of the application's web pages
  2. Confirming that the marketing copy on the website is accurate
  3. Checking authorization enforcement between partner tenants and rate limiting of API calls Correct answer.
  4. Measuring the battery consumption of the mobile client

Explanation

Partner-facing APIs must enforce tenant isolation and authorization on every call and resist abuse through rate limiting, which are distinctive security concerns for that interface. Layout, marketing text, and battery use are unrelated to API security.

Question 15Security testing planning

What is the most appropriate role of a threat model during security test planning?

  1. It defines the programming language to be used
  2. It serves as the final security audit report
  3. It provides a prioritized set of attack paths that guide which tests to design Correct answer.
  4. It replaces the need for any test execution

Explanation

Threat modeling identifies assets, trust boundaries, and plausible attack paths, which the plan converts into prioritized security test cases. It is an input to testing, not a substitute for execution, an audit report, or a technology selection document.

Question 16Security testing planning

A plan schedules a penetration test two days before go-live. Which planning risk does this create for the security test effort?

  1. The testers will be unable to use any automated tools
  2. The system will be exempt from compliance requirements
  3. Findings may arrive too late to be remediated and retested before release Correct answer.
  4. The penetration test will automatically invalidate prior unit tests

Explanation

Scheduling intrusive testing immediately before release leaves no time to fix and retest discovered weaknesses, so findings become accepted risk by default. It does not invalidate unit tests, prevent tool use, or waive compliance obligations.

Question 17Security testing planning

Which consideration is most important when planning the use of automated security scanning tools within a continuous delivery pipeline?

  1. Ensuring the tools produce zero findings so builds always pass
  2. Running scans only on the developer laptops
  3. Disabling all scanning during periods of frequent code changes
  4. Configuring thresholds and triage so that genuine high-risk findings block release while noise does not Correct answer.

Explanation

Automated scanners generate false positives and require calibrated thresholds plus triage so that serious findings gate releases without paralyzing delivery. Expecting zero findings, disabling scanning during active development, or restricting scans to laptops defeats the purpose.

Question 18Security testing planning

Which statement best describes how security test planning should treat accepted residual risk?

  1. Residual risk should be eliminated by declaring the system fully secure
  2. Residual risk should be hidden from the test plan to avoid alarming stakeholders
  3. Residual risk should be transferred to the test team as their personal liability
  4. Residual risk should be documented with an owner and rationale so it is consciously accepted Correct answer.

Explanation

Sound planning records residual risk explicitly, naming an accountable owner and the reasoning for acceptance, so that the decision is transparent and reviewable. Concealing it, denying its existence, or shifting liability to testers undermines governance.

Question 19Security testing planning

When planning security testing, why should test data be deliberately designed rather than taken directly from production?

  1. Production data cannot be loaded into any database
  2. Production data has no value for security testing
  3. Production data is always encrypted and therefore unusable
  4. Production data may contain personal or sensitive information that must not be exposed during testing Correct answer.

Explanation

Using live production data in security tests risks privacy violations and regulatory breach, so planning must specify masked or synthetic data that preserves realistic structure. Production data is not universally encrypted, unloadable, or worthless.

Question 20Security testing planning

A plan defines security test coverage purely by counting the number of test cases executed against each module. Which criticism is most valid?

  1. Test case counts are impossible to collect in practice
  2. Test case counts always overstate the number of testers required
  3. Test case counts cannot be reported to management
  4. Test case counts ignore whether the cases exercise meaningful threat scenarios and controls Correct answer.

Explanation

Volume of executed cases says nothing about whether high-risk threats and key controls were actually exercised, so it is a weak coverage proxy. Case counts are collectible, reportable, and unrelated to staffing estimates in this context.

Question 21Security testing planning

Which planning decision best supports repeatable security regression testing after each release?

  1. Replacing all security tests with a single annual audit
  2. Maintaining a curated set of security regression tests tied to previously found weaknesses Correct answer.
  3. Relying on ad hoc exploratory hacking by a different tester each time
  4. Removing tests for vulnerabilities that were already fixed

Explanation

A curated regression suite anchored to past weaknesses ensures that fixes stay fixed and that recurring risk areas are rechecked each release. Ad hoc efforts, annual audits, and deleting fixed-vulnerability tests all break repeatability and allow regressions.

Question 22Security testing planning

Which stakeholder group is most important to involve when agreeing the security test plan's acceptance criteria for a system handling financial transactions?

  1. Only the development team that wrote the code
  2. Business owners accountable for financial and regulatory risk, together with security specialists Correct answer.
  3. External hardware vendors only
  4. The facilities management team

Explanation

Acceptance criteria for security reflect tolerated business and regulatory risk, so accountable business owners must agree them with security specialists who understand the threats. Developer-only, vendor-only, or facilities involvement cannot authorize risk acceptance.

Question 23Security testing planning

A security test plan lists 'test the login page' as its only authentication test. Which planning gap is most significant?

  1. It omits related controls such as session management, password reset, and account lockout Correct answer.
  2. It specifies too many authentication scenarios
  3. It duplicates tests already covered by performance testing
  4. It should focus only on the visual appearance of the login page

Explanation

Authentication security spans credential handling, session lifecycle, recovery flows, and lockout behavior, so testing only the login page leaves major attack paths uncovered. The gap is under-coverage, not over-specification or duplication.

Question 24Security testing planning

Which approach best estimates the effort needed for security testing during planning?

  1. Reuse the functional test effort estimate unchanged
  2. Estimate from the number of identified threats and abuse cases plus environment and tooling setup needs Correct answer.
  3. Assume security testing requires no dedicated effort
  4. Base the estimate solely on the number of developers on the team

Explanation

Security effort depends on the number and complexity of threat scenarios to be exercised plus the setup of isolated environments and tooling, which differ from functional testing. Reusing functional estimates, assuming zero effort, or using team size alone ignores these drivers.

Question 25Security testing planning

Why should the security test plan define how findings will be triaged and reported before testing begins?

  1. To allow testers to decide unilaterally which findings to discard
  2. To remove the need for retesting after fixes
  3. To ensure findings are routed to the right owners with consistent severity and remediation tracking Correct answer.
  4. To guarantee that no vulnerabilities will be discovered

Explanation

Pre-agreed triage and reporting routes findings to accountable owners with consistent severity ratings and tracked remediation, preventing them from being lost or disputed. It cannot prevent findings, should not grant unilateral discarding, and does not eliminate retesting.

Question 26Security testing planning

During security test planning, which document most directly determines which regulatory security controls must be verified before release?

  1. The team's preferred automated scanning tool configuration
  2. The applicable compliance obligations identified for the product's market and data types Correct answer.
  3. The historical defect density of the development team
  4. The project's sprint velocity from previous releases

Explanation

Compliance obligations such as data protection laws, industry standards, and contractual clauses define mandatory security controls that testing must verify. Tooling, defect history, and velocity inform estimation and prioritization but do not establish which controls are legally or contractually required.

Question 27Security testing planning

A security test plan must define entry criteria. Which entry criterion is most appropriate before dynamic security testing of a web service begins?

  1. Every identified vulnerability has already been remediated and retested
  2. A deployable build exists in a representative environment with known test accounts Correct answer.
  3. All source code has been refactored to the team's coding standard
  4. The final penetration test report has been signed off by the business owner

Explanation

Dynamic security testing requires a running, representative build plus controlled credentials so testers can exercise authenticated functionality. Remediation and sign-off are exit conditions, and refactoring to a coding standard is a development quality gate rather than a prerequisite for dynamic testing.

Question 28Security testing planning

Which element belongs in the scope section of a security test plan rather than in its approach section?

  1. The list of interfaces, user roles, and data stores to be tested Correct answer.
  2. The technique used to derive abuse cases from threat models
  3. The tooling used to automate authentication fuzzing
  4. The reporting template for findings

Explanation

Scope defines what will and will not be examined, so enumerating interfaces, roles, and data stores belongs there. Techniques, tooling, and reporting templates describe how the work is performed and therefore belong in the approach or reporting sections.

Question 29Security testing planning

Why should a security test plan identify dependencies on external service providers before testing starts?

  1. Because access windows, test accounts, and throttling limits must be arranged in advance Correct answer.
  2. Because third-party systems are exempt from security testing obligations
  3. Because external providers always refuse to cooperate with security testers
  4. Because external dependencies eliminate the need for internal testing

Explanation

Testing systems that integrate with external providers requires coordinated access, credentials, and agreed limits on test traffic, all of which take lead time to arrange. Assuming providers will refuse, treating third parties as exempt, or dropping internal testing are all planning errors.

Question 30Security testing planning

Which item is a security test planning deliverable rather than a test execution activity?

  1. Recording the HTTP response of a failed authorization attempt
  2. Estimating effort and resources for the planned security tests Correct answer.
  3. Capturing evidence of a successful privilege escalation
  4. Exploiting a discovered injection flaw to confirm impact

Explanation

Estimating effort, resources, and schedule is a planning activity that produces the plan's resource and schedule sections. Recording responses, exploiting flaws, and capturing evidence are execution and analysis activities performed once testing is underway.

Question 31Security testing planning

Which characteristic distinguishes a security test plan from a functional test plan?

  1. It is owned exclusively by the operations team
  2. It is written only after all functional testing has been completed
  3. It excludes any consideration of functional requirements
  4. It focuses on adversarial conditions, misuse, and attacker goals in addition to expected behavior Correct answer.

Explanation

Security test planning extends beyond expected behavior to consider how an adversary could misuse the system, which drives abuse cases, threat-driven coverage, and negative testing. It is not sequenced after functional testing, does not ignore functional requirements, and is not owned solely by operations.

Question 32Security testing planning

A plan must state how security test results will be recorded. Which practice best supports later trend analysis across releases?

  1. Recording only the total count of findings per release
  2. Using a consistent finding schema with severity, category, and status fields Correct answer.
  3. Deleting resolved findings once a release ships
  4. Storing findings only in free-text emails sent to the project lead

Explanation

A consistent schema with standardized fields enables comparison, aggregation, and trend analysis across releases. Free-text emails, bare counts, and deletion of resolved findings all destroy the structure and history needed for meaningful trends.

Question 33Security testing planning

Which planning input tells the security tester which data classifications the system will handle and therefore how strict the testing must be?

  1. The data classification and privacy impact assessment Correct answer.
  2. The user interface style guide
  3. The continuous integration pipeline configuration
  4. The team's retrospective action list

Explanation

Data classification and privacy impact assessments identify the sensitivity of data handled, which directly drives the rigor of security testing and applicable controls. Pipeline configuration, retrospectives, and UI style guides do not establish data sensitivity.

Question 34Security testing planning

A team plans security testing for a payment feature that handles card data and a cosmetic profile-photo feature. How should the plan allocate testing depth?

  1. Equal depth because testing depth should never vary between features
  2. Equal depth for both features because both are user-facing
  3. Greater depth for the payment feature because of higher regulatory and financial risk Correct answer.
  4. Greater depth for the photo feature because images are larger files

Explanation

Test depth should be proportional to risk, and card data handling carries regulatory obligations and direct financial exposure that far exceed those of a cosmetic feature. Uniform depth ignores risk differences and misallocates limited effort.

Question 35Security testing planning

When planning security tests for a system that processes personal data under a privacy regulation, which planning element is most directly required?

  1. A list of marketing slogans approved for the release
  2. A performance benchmark for image rendering
  3. Verification of data subject rights such as access and deletion Correct answer.
  4. A review of the company's social media policy

Explanation

Privacy regulations typically grant data subjects rights such as access, correction, and deletion, so the plan must include verification that these are implemented correctly. Marketing slogans, rendering benchmarks, and social media policy are unrelated to privacy obligations.

Question 36Security testing planning

A security test plan allocates two days for a penetration test but does not reserve time for retesting fixes. Which planning weakness does this create?

  1. The environment will become more representative over time
  2. Testers will be forced to lower the severity of findings
  3. The penetration test will automatically cover more scope
  4. Findings may be reported without confirmation that remediation actually works Correct answer.

Explanation

Without scheduled retest time, remediation cannot be verified, so the plan cannot confirm that reported vulnerabilities were actually closed. Omitting retest does not expand scope, change severity assignment, or improve environment representativeness.

Question 37Security testing planning

A plan defines a security test cycle as complete when all planned test cases run, regardless of whether high-severity findings were fixed. Which planning correction is most appropriate?

  1. Shorten the test cycle to finish earlier
  2. Remove severity ratings so all findings are treated equally
  3. Add exit criteria requiring remediation and retest of critical and high findings Correct answer.
  4. Increase the number of test cases to compensate

Explanation

Exit criteria should reflect security outcomes, not just activity, so requiring remediation and retest of critical and high findings makes completion meaningful. Removing severity, adding volume, or shortening the cycle does not address the missing quality gate.

Question 38Security testing planning

Which planning technique best ensures that security test coverage follows the system's actual attack surface?

  1. Deriving tests from an architecture-based threat model of entry points and trust boundaries Correct answer.
  2. Reusing the previous release's test cases without modification
  3. Selecting tests based on alphabetical order of module names
  4. Limiting tests to the modules with the most lines of code

Explanation

A threat model built on architecture identifies entry points, assets, and trust boundaries, which lets the plan target tests where attacks are actually feasible. Reuse without review, alphabetical ordering, and code size are not risk-based selection methods.

Question 39Security testing planning

A plan must choose between manual expert security testing and automated scanning for a short release window. Which planning approach is most defensible?

  1. Use only manual testing because tools never find real issues
  2. Combine automated scanning for breadth with targeted manual testing for high-risk logic Correct answer.
  3. Defer all security testing until after the release
  4. Use only automated scanning because it requires no expertise

Explanation

Automated scanning gives broad, repeatable coverage cheaply, while manual expert testing is needed for business-logic and authorization flaws that scanners miss. Relying on either alone leaves gaps, and deferring testing removes the safety net entirely.

Question 40Security testing planning

When planning security testing for a mobile application, which planning consideration most distinguishes it from a purely server-side web application?

  1. Client-side storage and tampering risks on the device must be tested Correct answer.
  2. The server never needs security testing
  3. Network latency is irrelevant to mobile apps
  4. Mobile apps cannot use authentication

Explanation

Mobile apps store data and execute logic on a device the attacker may control, so insecure local storage, tampering, and reverse engineering become distinct test targets. The server remains in scope, latency matters, and mobile apps commonly use authentication.

Question 41Security testing planning

A plan proposes testing only the production environment to avoid building a separate test environment. Which planning concern is most significant?

  1. Production environments cannot run automated tools
  2. Production is always less representative than a test environment
  3. Production testing may disrupt real users and data while still lacking safe test data Correct answer.
  4. Production testing eliminates the need for authorization

Explanation

Testing in production risks harming real users and data and complicates safe test data handling, which is why controlled environments or carefully isolated production testing are usually planned. Production is the most representative environment, authorization is still required, and tools can run there.

Question 42Security testing planning

Which planning action best ensures that security findings reach the people who can fix them quickly?

  1. Reporting findings only in the final release retrospective
  2. Defining severity thresholds and routing rules to responsible owners in the plan Correct answer.
  3. Sending all findings to a general inbox without owners
  4. Publishing raw tool output without triage

Explanation

Agreeing severity thresholds and routing rules up front ensures each finding reaches an accountable owner with appropriate urgency. A general inbox, retrospective-only reporting, and untriaged raw output all delay or obscure remediation responsibility.

Question 43Security testing planning

When planning security testing for a system that will be operated by a third party, which planning element is most important to agree contractually?

  1. The rules of engagement, notification duties, and permitted test techniques Correct answer.
  2. The color scheme of the security dashboard
  3. The names of the developers who wrote the code
  4. The marketing launch date

Explanation

For third-party-operated systems, the plan must align with contractual rules of engagement, incident notification duties, and permitted techniques to avoid legal or operational problems. Dashboard styling, developer names, and launch dates are not security testing terms.

Question 44Security testing planning

A security test plan for a microservice architecture lists each service but omits inter-service authentication. Which planning gap does this represent?

  1. An overestimation of test effort
  2. A missing trust-boundary analysis between services Correct answer.
  3. A redundant test of user interfaces
  4. An excessive focus on availability

Explanation

Inter-service authentication sits on trust boundaries, and omitting it means the plan has not analyzed how trust is established between components. The gap is not about availability, UI redundancy, or effort estimation.

Question 45Security testing planning

Which planning practice best keeps security test coverage aligned as requirements change during a project?

  1. Removing security tests whenever the schedule tightens
  2. Reviewing and updating security test coverage at defined checkpoints tied to requirement changes Correct answer.
  3. Freezing the security test plan at project start and never revising it
  4. Assigning security testing to a single person with no review

Explanation

Security coverage must be revisited at defined checkpoints so that new requirements, interfaces, and risks are reflected in the tests. Freezing the plan, dropping tests under schedule pressure, and isolating the work without review all erode coverage.

Question 46Security testing planning

A team must plan security testing for a legacy system with no documentation. Which planning step is most valuable first?

  1. Assume the system is secure because it has operated for years
  2. Test only the login page and consider coverage complete
  3. Skip security testing because documentation is missing
  4. Perform reconnaissance to map components, interfaces, and data flows before defining tests Correct answer.

Explanation

When documentation is absent, reconnaissance is needed to discover components, interfaces, and data flows so that meaningful tests can be scoped. Assuming security, skipping testing, or testing a single page leaves the real attack surface unexamined.

Question 47Security testing planning

A plan budgets for one penetration test near the end of a long project. Which planning change most improves the value of security testing without abandoning the penetration test?

  1. Replace the penetration test with a code style review
  2. Move the penetration test to the first week and cancel all later testing
  3. Add lightweight security checks and threat review at each iteration alongside the final penetration test Correct answer.
  4. Increase the penetration test duration to cover the whole project

Explanation

Distributing lightweight checks and threat review across iterations finds and fixes issues when they are cheap to correct, while the final penetration test still provides independent assurance. Moving the test to week one, replacing it with style review, or stretching a single test across the project does not achieve both goals.

Question 48Security testing planning

A plan states that security testing will reuse production customer records to save time. Which planning risk is most serious?

  1. Test execution will be slower than with synthetic data
  2. The database schema may differ from production
  3. Testers will need to learn the data model
  4. Sensitive personal data may be exposed or misused during testing Correct answer.

Explanation

Reusing real customer records exposes personal data to testers and tools and may breach privacy obligations, so plans should use masked or synthetic data with equivalent characteristics. Speed, learning curve, and schema differences are lesser concerns compared with unlawful data exposure.

Question 49Security testing planning

A plan must prioritize testing across many modules under a fixed budget. Which planning method gives the most defensible prioritization?

  1. Rank modules by the product of threat likelihood and business impact, then allocate effort accordingly Correct answer.
  2. Rank modules by the length of their names
  3. Rank modules by the age of the source files
  4. Rank modules by the number of developers who touched them

Explanation

Combining threat likelihood with business impact produces a risk score that directs limited effort toward the exposures that matter most. Developer count, file age, and name length are proxies unrelated to adversarial risk.

Question 50Security testing planning

A security test plan is written entirely by the testing team and never reviewed by development, operations, or the business owner. Which consequence is most likely?

  1. The plan will be shorter than necessary
  2. Test execution will require no coordination
  3. The plan will automatically become more secure
  4. Key constraints and risks known to other groups will be missed, reducing relevance Correct answer.

Explanation

Security testing spans architecture, operations, and business risk, so without cross-group review the plan is likely to miss constraints, dependencies, and risks those groups understand. Length, automatic security improvement, and coordination-free execution are not plausible outcomes of isolation.