Free Information Systems Security Engineering Professional (ISSEP) practice test: 30 questions with answers

Zero trust removes implicit trust based on network location, so each request is authenticated, authorized, and evaluated continuously. Perimeter-based and implicit trust both assume internal traffic is safe once it passes a boundary, and least common mechanism is a design principle about minimizing shared mechanisms rather than a trust model.

Fail-safe defaults is the Saltzer and Schroeder principle that a default or failure leads to denial rather than access. Economy of mechanism concerns simplicity, open design concerns whether the design must stay secret, and psychological acceptability concerns usability.

Model-based systems engineering keeps requirements, design, and verification linked in connected models so traceability is maintained as the system evolves. Document-centric review, informal tracing, and phase gating do not provide the same live traceability between needs and verification.

Threat analysis during requirements and design reviews at milestones are early, repeated security activities that the lifecycle depends on. Testing only after deployment, adding controls only after audit findings, and unreviewed developer decisions push security to the end or remove it, which is the opposite of integration.

Configuration management maintains the integrity of approved baselines by controlling, recording, and authorizing changes. The other options either trade security review for speed or substitute scans for documented requirements, which does not produce an approved, auditable change history.

Provenance and component documentation, checked against delivered items, directly addresses tampering and supply chain integrity. Choosing the lowest bid or relying on warranty terms does not verify integrity, and the other options address delivery flexibility or a one-time test with no ongoing vendor review.

Least privilege grants only the access needed for the task and only for as long as it is needed. Permanent group membership, a shared account, and full access based on network location all grant more than the task requires.

Defense-in-depth uses multiple, independent layers so an attacker must defeat several controls. A single perimeter, identical duplicated controls, or encryption as the only safeguard do not provide layered protection.

Stakeholder security needs come from how the mission will operate and what threatens it, so analyzing the concept of operations with the users and mission owners is the right activity. Product features, late requirements, and developer preference do not reflect those needs.

A requirements baseline is an approved reference set managed under change control. A running list of suggestions, warranty terms, or a freely edited draft does not provide the stable reference that a baseline is meant to be.

A trade-off study weighs security, performance, and mission criteria across alternatives with stakeholder involvement. Ignoring the timing requirement, dropping the security concern, or deferring the decision until production each skip that analysis.

Separation of duties splits a critical process among different people so that no one can complete it alone. The other principles concern checking every access, sharing mechanisms, and secrecy of design, and none of them requires splitting a payment across two people.

Using common scales so system risks can be compared with enterprise risks is alignment with enterprise risk management. Replacing the register, transferring every risk to insurance, or accepting everything below the top rating each break the shared view that the request is trying to create.

Mitigation reduces risk through added or improved controls. Transfer shifts consequences, avoidance removes the activity, and acceptance keeps the risk unchanged, so each of the other options is a different response.

The impact is measured in mission and business terms, which is risk to operations. The other options measure risk by asset cost, code volume, or contract payments, and none of them captures the harm to patient care described in the scenario.

Residual risk is what remains after controls are applied, and it is the basis for the authorization decision. Inherent risk is measured before controls, a tolerance threshold is a limit rather than a risk, and a prioritized backlog is a planning list.

The decision to accept risk depends on the residual risk and how it compares with the organization's risk tolerance, as documented in the assessment. Vendor claims, helpdesk volume, and a list of controls with no risk context do not show what risk remains.

Risk tolerance defines the acceptable level of risk, and residual risk must be reassessed as the system or threat environment changes. Monitoring continues after authorization, responses are revisited over time, and a register should capture identified risks before they cause incidents.

Verification asks whether the system was built to its specifications, and validation asks whether it satisfies the stakeholders' actual needs. The other statements assign the wrong meanings, restrict the activities to certain parties, or treat the two as synonyms.

Automated gates in the CI/CD pipeline enforce security checks on every change and can block merges, which is the DevSecOps practice described. Quarterly tests, manual release-note review, and annual audits happen too rarely or too late to block individual commits.

A traceability matrix shows each requirement is tested, and predefined pass criteria show what a passing result means. A schedule, a script count, and vendor brochures say nothing about whether the security requirements are actually covered.

Reviewing test results and residual risk supports formal stakeholder acceptance and the authorization decision. Patching is an operational task, removing audit logging weakens accountability, and developer self-certification is not an independent acceptance.

Integration can change security behaviour even when components pass alone, so the integrated security functions need re-testing and documentation before acceptance. Assuming safety from unit tests, disabling access control, or deferring review to an audit all leave the changed behaviour unverified.

Test results are only as representative as the environment, so the difference must be disclosed and the critical tests repeated where production controls apply. Reporting the results as complete, cancelling the test, or dropping application tests each hide or discard the evidence needed for acceptance.

Continuous monitoring checks control effectiveness throughout the system's life and reports changes to the authorizing official. A one-time scan or annual paperwork review cannot show drift, and offline log storage does not assess whether controls work.

A change impact assessment examines how an upgrade affects controls, configurations, and the risk assessment before approval. A vendor certification, a weekend window, or assuming the change is harmless bypasses that analysis.

Sanitization methods such as purging or cryptographic erase are designed to make recovery of the data infeasible, matched to the sensitivity of the data. Deleting files, quick formatting, and storing the media do not remove the underlying data reliably.

Decommissioning must protect regulated data, close accounts and connections, and keep the inventory accurate. Extending support, adding features, and marketing the replacement do not reduce risk, and some of them add new exposure.

Gradual changes can signal an emerging problem even when no single event crosses a threshold, so the trend should be investigated with the owner. Ignoring it, raising the threshold, or waiting for the annual assessment hides or delays evidence of change.

A secure operations plan records how the system runs, is maintained, and is protected day to day, including roles, procedures, and responsibilities. The other options describe procurement claims, development budgets, or future release features, which are not operational security content.