6.1 Assessment, Testing & Audit Strategy
6.1 Assessment, Testing & Audit Strategy
Security testing should not begin by simply launching a scanner, scheduling a penetration test or asking an auditor to "check security."
A good strategy first establishes:
what needs assurance, why it is being assessed, how much assurance is required, who should perform the work and what evidence will be needed.
Define
Establish objectives, scope, requirements and risk.
WHAT & WHY?Assess
Select suitable assessment, testing and audit approaches.
HOW?Validate
Confirm that the strategy produces sufficient, credible evidence.
ENOUGH ASSURANCE?Design and Validate Assessment, Test, and Audit Strategies
Assessment activities conducted within organisational control.
Assessment from outside organisational control or from an external perspective.
Assessment involving independent organisations, suppliers, partners or services outside enterprise control.
The strategy must account for on-premises, cloud and hybrid environments.
6.1 Scope
The Big Idea
Security assessment is not primarily about generating findings.
It is about producing credible evidence that allows the organisation to understand whether security requirements and controls are working as intended.
Assessment Strategy
Assessment vs Testing vs Audit
Broad evaluation of security controls, systems, processes or risk.
It can use documentation, interviews, technical evidence and tests.
ARE CONTROLS EFFECTIVE?
Exercises a control, mechanism or system to observe its actual behaviour.
DOES IT WORK?
Systematic examination of evidence against defined criteria, requirements, policy or obligations.
DOES IT CONFORM?
Assessment · Test · Audit
An assessment may contain tests. An audit may examine technical test evidence. A penetration test may form part of a wider assurance strategy.
What Are We Trying to Determine?
A useful assessment strategy tests more than whether a control merely exists.
Is the control appropriately designed to address the requirement or risk?
Has the control actually been put in place?
Is the control being used in practice?
Is it achieving the intended security objective?
Does it operate across the expected population and environment?
Does it continue operating over time?
Control Assurance
🎯 Start With the Objective The tool comes after the question
"We bought a vulnerability scanner, so let's scan everything."
"We need assurance that externally exposed systems are not carrying known high-risk vulnerabilities."
From that objective, the organisation can determine:
Inputs to an Assessment Strategy
Which business services and outcomes need protection?
Which threats, vulnerabilities and impacts require assurance?
Which security objectives and requirements must be satisfied?
Which internal requirements must be tested?
Which external obligations affect assessment or audit activity?
Which customer, supplier or service commitments require assurance?
Which systems warrant deeper or more frequent assessment?
Has architecture, software, configuration or business use changed?
Which weaknesses require retesting or additional scrutiny?
Have new threats changed the required assurance?
Build the Assessment Plan
🎯 Scope Know exactly what is and is not being assessed
Scope Can Include
Define Boundaries
"Test the website."
"Assess the production customer web application, its externally accessible APIs and authentication service. Exclude the payment processor because separate authorization has not been obtained."
📏 Assessment Criteria A finding needs something to be measured against
Before testing, identify the criteria used to determine whether the observed state is acceptable.
Internal organisational requirements.
Mandatory technical or organisational rules.
Expected security outcome.
Agreed obligations with another party.
Applicable legal requirement.
Expected configuration or implementation state.
Audit Logic
Examine · Interview · Test
A strong assessment strategy can combine multiple forms of evidence.
Review or inspect documents, records, configurations, mechanisms or activities.
Discuss processes and control operation with relevant people.
Exercise mechanisms or processes and observe their actual behaviour.
Assessment Evidence
🔺 Corroborate Evidence Do not rely on one evidence source when stronger assurance is required
"Terminated user access is removed within four hours."
HR and IAM teams describe the leaver process.
Review offboarding procedures and a sample of completed records.
Verify that selected former-user accounts are actually disabled.
Depth & Coverage
Not every assessment needs the same level of effort.
How rigorous and detailed should the assessment be?
HOW DEEPLY?
How much of the population, environment or control implementation should be examined?
HOW MUCH?
Review configuration documentation and a small representative sample.
Use deeper technical testing, stronger evidence, wider sampling and independent review.
Depth vs Coverage
🎲 Sampling You may not be able to inspect every event or control instance
Large environments often require sampling.
The sample should provide meaningful evidence for the assessment objective.
The organisation processed:
12,000 privileged-access requests.
An assessor may inspect an appropriate sample rather than manually reviewing every request.
Consider
Selecting only the easiest or best-performing examples can create false assurance.
Internal Assessment
Internal assessment is performed within organisational control and often uses internal security, assurance, engineering or audit capabilities.
Advantages
Risks / Limitations
Internal testing can provide excellent assurance when assessors have sufficient competence, objectivity and organisational authority.
🪞 Self-Assessment The team responsible for a control evaluates its own implementation
The team understands the environment and can assess frequently.
The same team may be evaluating work that it designed or operates.
External Assessment
An external strategy evaluates security from outside the organisation's normal internal control or trust boundary.
Test the organisation's internet-facing services from the perspective of an unauthenticated external attacker.
Useful For
An internal scan may reveal vulnerabilities that an external actor cannot reach.
An external assessment may reveal exposure that internal teams did not realise was publicly accessible.
Internal vs External Perspective
What can an internet-based attacker see or reach?
What can a compromised employee account, endpoint or internal attacker reach?
Externally: database is unreachable.
Internally: database is reachable from every workstation.
Both observations matter, but they answer different questions.
Perspective
Third-Party Assessment
Third-party assurance can involve independent assessors, suppliers, managed services, cloud providers and other organisations outside enterprise control.
Provides an outside assessment of the organisation's controls or systems.
Determines whether a supplier's security is sufficient for the organisation's risk.
Evaluates controls associated with externally operated services.
Existing independent evidence may be used where appropriate rather than repeating identical testing.
📑 Using Third-Party Assurance Do not accept a report merely because it exists
Ask
A cloud supplier provides an independent security report.
The report covers:
the supplier's European platform.
Your service runs:
in a different environment excluded from the report.
The report may provide useful assurance, but it does not automatically prove that your service is covered.
Third-Party Evidence
Independence
Independence can increase confidence that conclusions are objective and not unduly influenced by the team responsible for the control being evaluated.
Control owner tests their own implementation.
Separate internal assurance or security team performs the assessment.
Independent third-party assessor conducts the engagement.
Routine operational checking may be performed internally.
High-risk, regulatory or formal assurance may justify greater independence.
Independence
🧠 Assessor Competence Independent does not automatically mean competent
Select assessors according to the knowledge and skills required for the engagement.
An external assessor who does not understand the technology or environment may provide less useful assurance than a competent internal specialist.
Location Matters
Assessment strategy must reflect where systems, data and controls actually operate.
Organisation directly controls much of the physical infrastructure, network and supporting technology.
Assessment must consider provider responsibilities, customer responsibilities and platform-specific testing restrictions.
Assurance must cover trust boundaries and dependencies between on-premises and cloud environments.
Location
🏢 On-Premises Assessment Infrastructure may be under direct organisational control
Possible Scope
But production impact, safety and business availability still need to be considered.
☁️ Cloud Assessment Test what you control and understand what the provider controls
Cloud environments introduce shared responsibility.
Identity, configuration, workloads, data, permissions and other customer-managed responsibilities.
Physical infrastructure and provider-managed technology may require reliance on provider assurance.
An organisation cannot physically inspect every disk in a hyperscale provider's data centre.
It may instead use appropriate provider assurance for provider-managed controls while directly testing its own cloud configuration and identities.
📜 Cloud Testing Authorization Owning a workload does not necessarily mean you can test the provider however you want
Before conducting intrusive testing in a hosted environment, determine what the provider permits.
🔄 Hybrid Assessment The boundary between environments is often where risk appears
Assess the Interfaces
Rules of Engagement
Intrusive security testing should operate under clear authorization and boundaries.
Which assets may be tested?
Which activities are permitted or prohibited?
When may testing occur?
Who must be notified if something goes wrong?
When must the assessment immediately stop?
How will sensitive information obtained during testing be protected?
Rules of Engagement
✍️ Testing Authorization Permission is a prerequisite, not an administrative afterthought
A security engineer discovers a supplier-hosted server used by the organisation.
They decide to perform aggressive penetration testing against it.
The organisation uses the server but:
does not own or control the underlying infrastructure.
Production Safety
Security testing itself introduces operational risk.
Scanning and testing may consume significant resources.
Some techniques may crash or destabilise services.
Exploitation may change production data.
Security tools may treat legitimate testing as a real attack.
Testing may affect shared infrastructure or other customers.
Some environments require extremely conservative testing.
🧯 Managing Testing Risk Choose the safest method that still provides adequate assurance
A legacy production system is known to crash under aggressive scanning.
The strategy may use:
- configuration examination;
- targeted safe tests;
- a representative non-production environment;
- additional monitoring during any production validation.
The test should produce enough evidence without creating unjustified business risk.
🧪 Production vs Non-Production Testing Safety and realism create a trade-off
Provides evidence about the real environment.
But failures can affect real business operations.
Reduces operational impact.
But results are useful only if the environment is sufficiently representative.
Good Evidence Supports the Conclusion
The evidence relates directly to the assessment objective.
The source and collection process can be trusted.
There is enough evidence to support the conclusion.
Findings can be connected to the evidence that supports them.
Evidence reflects the period or state being assessed.
Sensitive assessment evidence is appropriately secured.
"The administrator told us backups work."
Review backup configuration, examine completion records and observe or test an appropriate restoration process.
🔐 Protect Assessment Evidence Security testing can generate highly sensitive information
Assessment evidence may include:
Plan
How Often Should We Assess?
Assessment frequency should reflect risk rather than an arbitrary belief that every control must be tested at the same interval.
More important systems may justify more frequent assurance.
Rapidly changing systems can invalidate old evidence quickly.
Changing threat conditions may require additional assessment.
Stable controls may require different monitoring from frequently changing controls.
Contracts, regulation and policy may establish minimum frequencies.
Repeated failures may justify more frequent validation.
Assessment Frequency
📡 Continuous Monitoring Continuous does not necessarily mean every second
Continuous monitoring provides ongoing awareness of security controls, vulnerabilities, threats and changes at a frequency appropriate to risk.
- cloud configuration may be checked continuously;
- vulnerability scanning may occur regularly;
- privileged-access reviews may occur periodically;
- physical-security exercises may occur less frequently.
Continuous Monitoring
Point-in-Time vs Ongoing Assurance
Provides assurance about conditions at a particular period or moment.
Annual penetration test.
Repeated monitoring helps detect security changes between formal assessments.
Continuous cloud configuration monitoring.
⚡ Event-Driven Assessment Do not wait for the calendar when risk has materially changed
Possible Triggers
A penetration test was completed two months ago.
The application is then completely redesigned and moved to a new cloud architecture.
The previous test may no longer provide sufficient assurance for the new design.
Assessment Trigger
Automated vs Manual Assessment
Efficient for repeatable, machine-readable checks across large environments.
Useful where human judgement, context or complex behaviour must be understood.
An automated tool can determine:
MFA is configured.
A deeper assessment may determine:
administrators can bypass MFA through an undocumented legacy login path.
🔔 False Positives & False Negatives Tool output is evidence to analyse, not unquestionable truth
The assessment reports a problem that is not actually present.
A real problem exists but the assessment fails to detect it.
False Results
"No findings" does not necessarily mean "no vulnerabilities."
🔭 Understand Test Limitations Every assessment has boundaries
A vulnerability scan finds no known vulnerabilities.
This does not prove:
- the application has no business-logic flaws;
- access-control design is correct;
- staff follow procedures;
- the system contains no unknown vulnerabilities;
- every asset was actually scanned.
Risk-Based Assessment Strategy
Assessment resources are finite.
The highest assurance effort should generally be directed toward areas where failure would create the greatest risk.
Risk-Based Testing
🧰 Use Complementary Assessment Methods No single test answers every security question
A penetration test may find exploitable paths. A code review may identify flaws the tester never reaches. A configuration review may find insecure settings. An audit may identify missing governance.
Is the Strategy Strong Enough?
Designing a strategy is only half of objective 6.1.
The strategy itself should also be validated.
Ask
✅ Validate the Strategy Challenge whether the assurance plan can answer the real question
Provide assurance that privileged cloud access is appropriately controlled.
Interview the cloud administrator once per year.
Does that prove:
- who currently holds privileged roles?
- whether MFA is enforced?
- whether emergency accounts exist?
- whether old privileges are removed?
- whether privileged activity is logged?
Add role/configuration examination, account evidence and technical validation.
Assessing an Online Banking Platform
The organisation wants assurance before a major customer-facing release.
Assessing a SaaS Provider
A Critical Supplier Provides an Audit Report
The supplier says:
"We have already been independently audited."
Before Relying on It, Review
One Annual Penetration Test
An organisation conducts one penetration test every January.
Management therefore claims:
"Our systems are secure for the year."
New cloud infrastructure deployed.
New customer API launched.
Authentication architecture replaced.
Critical new vulnerability disclosed.
🎓 CISSP Scenarios Identify the assessment-strategy principle
A security manager immediately purchases a penetration test without first identifying what assurance management needs.
What should happen first?
Define the assessment objective.
Management wants to determine whether privileged-access controls are actually effective.
What should the strategy define next?
Appropriate scope, criteria, methods and evidence.
An assessor reviews policies, configurations and audit records.
Which assessment method?
Examine.
An assessor speaks with system administrators to understand how privileged accounts are provisioned.
Which assessment method?
Interview.
An assessor attempts to perform an operation that policy says should be blocked.
Which method?
Test.
A control owner states that account deprovisioning always happens within four hours.
What should provide stronger assurance?
Corroborate the statement with records and testing.
The assessment thoroughly tests only one server out of 20,000.
Which strategy consideration?
Coverage.
An assessment checks 5,000 systems but performs only a superficial configuration check.
Which consideration may be weak?
Depth.
A development team assesses the security controls it designed and implemented.
Which concern?
Assessor independence / objectivity.
An independent security team within the organisation tests controls operated by another department.
Which strategy?
Internal assessment with greater independence.
A completely separate organisation performs the formal security assessment.
Which assurance characteristic increases?
Independence.
The external assessor has no experience with cloud environments.
Primary concern?
Assessor competence.
The organisation wants to know what an unauthenticated attacker can discover from the internet.
Which assessment perspective?
External.
The organisation wants to understand what a compromised employee endpoint can reach inside the network.
Which perspective?
Internal.
A cloud supplier provides independent evidence about controls it operates.
Which strategy context?
Third-party assurance.
A supplier provides a security report, but the service used by the organisation is excluded from the report's scope.
Can the organisation rely on the report for that service?
Not without additional appropriate assurance.
A supplier provides an assessment performed four years ago.
Which concern?
Evidence currency / timeliness.
A company wants to penetration-test infrastructure operated by a hosting provider.
What should be confirmed first?
Authorization and provider testing requirements.
An organisation can test its cloud configuration but cannot directly inspect the provider's physical data-centre controls.
Which concept?
Shared responsibility and third-party assurance.
On-premises systems and cloud workloads are both secure individually, but nobody has assessed the identity federation connecting them.
What has been missed?
The hybrid trust boundary / integration.
A penetration tester discovers another company's IP address in the target environment and starts attacking it.
Primary issue?
Testing outside authorised scope.
A security test may crash a critical production system.
What should the strategy consider?
Operational risk, safe alternatives and stop conditions.
Management moves all testing to a laboratory environment that differs significantly from production.
Primary concern?
The environment may not provide representative evidence.
A scanner reports a critical vulnerability that manual investigation confirms does not exist.
Which result?
False positive.
A vulnerability exists but the testing process reports the system as clean.
Which result?
False negative.
A scan returns no findings, so management concludes that the application contains no security weaknesses of any kind.
What is wrong?
The conclusion exceeds what the testing method can demonstrate.
A penetration-test report contains exploit details and administrator credentials.
How should it be treated?
As sensitive security information.
Every security control is assessed annually regardless of criticality or how rapidly it changes.
What would improve the strategy?
Risk-based assessment frequency.
A highly dynamic cloud configuration is checked once per year.
Primary concern?
Assessment frequency may be insufficient for the rate of change.
Automated checks evaluate cloud configuration every few minutes.
Which assurance approach?
Continuous / ongoing monitoring.
Management assumes "continuous monitoring" means every control must literally be tested every second.
Is this correct?
No.
Monitoring frequency should be sufficient to support risk-based decisions.
A major system redesign occurs immediately after the annual security assessment.
Should the organisation simply wait until next year?
Not necessarily. Material change can trigger reassessment.
An automated tool verifies that MFA is enabled but does not detect a legacy authentication path that bypasses it.
Which lesson?
Automated testing may require complementary manual assessment.
An assessment strategy produces hundreds of technical findings but none relate to the organisation's critical business risks.
Primary problem?
Poor risk alignment.
A critical system receives deeper testing and wider coverage than a low-impact internal utility.
Which principle?
Risk-based assurance.
An organisation checks its backup policy and backup success logs but never attempts recovery.
Which evidence is missing?
Testing that demonstrates restoration actually works.
An audit identifies that a required control is documented but not operating.
What distinction matters?
Control existence does not prove control effectiveness.
A cloud provider's assurance evidence covers its infrastructure while the customer separately tests its own IAM configuration.
Which principle?
Assessment aligned with shared responsibility.
A test is performed exactly as planned but cannot answer the business assurance question.
What failed?
The assessment strategy.
Before approving a security assessment programme, the CISO asks whether its scope, depth, coverage, independence and frequency are sufficient for the organisation's risk.
Which part of 6.1?
Validating the assessment strategy.
Recognise the Clue Words
What Are We Trying to Prove?
Begin planning.
ObjectiveWhich Assets?
Define boundaries.
ScopeWhat Should Be?
Comparison requirement.
CriteriaReview Documents
Gather evidence.
ExamineTalk to Personnel
Understand process.
InterviewExercise Mechanism
Observe behaviour.
TestHow Deeply?
Rigor.
DepthHow Much?
Population.
CoverageInside Organisation
Organisation-controlled activity.
InternalInternet Perspective
Outside attack surface.
ExternalSupplier / Independent Firm
Outside enterprise control.
Third-PartyProvider Controls
Cloud dependency.
Third-Party AssuranceOn-Prem + Cloud
Assess interfaces too.
HybridWho Can We Attack?
Testing boundaries.
Rules of EngagementPermission to Test?
Before intrusive activity.
AuthorizationTest May Crash System
Control assessment risk.
Operational SafetyResult Says Problem, None Exists
Incorrect alarm.
False PositiveProblem Exists, Test Misses It
False assurance.
False NegativeIndependent Evaluator
Reduce bias.
IndependenceEnvironment Changes
Previous evidence may expire.
ReassessEvery Control Same Frequency
Better approach?
Risk-Based FrequencyOngoing Awareness
Risk-based frequency.
Continuous MonitoringDoes Plan Produce Enough Assurance?
Challenge the plan.
Validate Strategy⚠️ Common CISSP Mistakes 6.1 is about strategy before technique
Define the objective before selecting the scanner, auditor or penetration-testing technique.
Assessment can include examination, interviews, testing and many other evidence sources.
Audit evaluates evidence against defined criteria or requirements.
Design, implementation, operation and effectiveness are different assurance questions.
Higher assurance may require corroboration with documentary and technical evidence.
Testing should be proportionate to risk and the assurance objective.
Depth asks how rigorously something is assessed.
Coverage asks how much of the population is assessed.
An internal assessment can have varying degrees of independence.
Relationship, competence and conflicts of interest should still be considered.
The assessor still needs appropriate skills and experience.
Confirm scope, period, exceptions and relevance.
Test the controls you are responsible for and obtain appropriate assurance for provider-managed controls.
Confirm provider authorization and testing policy.
Connections and trust relationships require assessment too.
Differences from production can reduce the value of test results.
Every testing method has limitations and can produce false negatives.
Human judgement may be required for complex controls and business context.
Significant change may invalidate previous assurance.
Frequency should be sufficient to support risk-based decisions.
Findings and testing artefacts can be highly sensitive.
A technically excellent test can still answer the wrong assurance question.
Quick Reference
| If you see... | Think... |
|---|---|
| What do we need to learn? | Assessment Objective |
| Which assets or controls? | Scope |
| Compared against what? | Criteria |
| Review records / configuration | Examine |
| Discuss with personnel | Interview |
| Exercise control | Test |
| How rigorous? | Depth |
| How much? | Coverage |
| Inside organisational control | Internal |
| Outside attacker perspective | External |
| Independent supplier / provider evidence | Third-Party |
| Reduce assessor bias | Independence |
| Can assessor perform work properly? | Competence |
| Allowed target and techniques | Rules of Engagement |
| Permission before intrusive test | Authorization |
| Cloud provider's responsibility | Provider Assurance |
| On-prem and cloud together | Hybrid Assessment |
| Reported flaw not actually present | False Positive |
| Real flaw not detected | False Negative |
| Major architecture change | Reassessment Trigger |
| Ongoing risk awareness | Continuous Monitoring |
| Different frequencies according to risk | Risk-Based Monitoring |
| Does the assessment plan answer the real question? | Strategy Validation |
Assessment Method Memory Aid
Show · Tell · Prove
6.1 Context Memory Aid
Assessment Strategy Memory Aid
6.1 Master Memory Aid
Objective → Scope → Method → Evidence → Assurance
The Assessment Strategist's Questions
Key Takeaways
CISSP 6.1 focuses on designing and validating assessment, testing and audit strategies before individual testing techniques are performed.
The official objective specifically includes internal, external, third-party and location-based considerations covering on-premises, cloud and hybrid environments.
Assessment broadly evaluates systems, controls or processes to determine whether security objectives are being achieved.
Testing exercises mechanisms or processes to observe their actual behaviour.
Audit systematically compares evidence against defined criteria, requirements or obligations.
Assessment asks "is it effective?", testing asks "does it work?" and audit asks "does it conform?"
A good strategy begins with the assurance objective rather than the tool or testing technique.
The scope should clearly identify systems, controls, locations, interfaces and exclusions.
Assessment criteria define the expected state against which evidence will be evaluated.
NIST identifies three fundamental control-assessment methods: examine, interview and test.
Examination reviews artefacts, mechanisms and activities.
Interviews gather information from people who design, manage, operate or use controls.
Testing exercises mechanisms and observes actual behaviour.
Combining several evidence sources can provide stronger assurance than relying on one source alone.
Depth refers to how rigorously the assessment is performed.
Coverage refers to how much of the relevant population or environment is assessed.
Depth = how deeply. Coverage = how much.
Sampling can be appropriate where inspecting the entire population is impractical, but the sample should provide meaningful evidence.
Internal assessments can benefit from organisational knowledge and ease of repetition but may introduce objectivity concerns.
External assessment can provide an outside perspective on exposed systems and attack surfaces.
Third-party assurance may provide independent evidence or assurance about controls outside enterprise control.
Third-party evidence should be reviewed for scope, period, relevance, independence and exceptions before it is relied upon.
Assessor independence can increase confidence in the objectivity of assessment results.
Independence should be proportionate to the assurance requirement.
Independence alone is insufficient; assessors must also have appropriate competence.
On-premises, cloud and hybrid environments require different assessment considerations.
Cloud environments require understanding of shared responsibility and which controls can be tested directly versus those requiring provider assurance.
Hybrid assessment should include the trust relationships, data flows and interfaces connecting environments.
Intrusive security testing should operate under clear authorization, scope and rules of engagement.
Rules of engagement can define permitted targets, techniques, timing, contacts, stop conditions and evidence handling.
Using or consuming a third-party service does not automatically grant permission to conduct intrusive testing against it.
Security testing can itself create operational risk.
Production testing therefore requires consideration of availability, safety, monitoring, rollback and potential impact.
More intrusive testing is not automatically better testing. The strategy should obtain sufficient assurance without creating unjustified business risk.
Non-production environments reduce operational risk but provide useful evidence only when they are sufficiently representative of production.
Assessment evidence should be relevant, reliable, sufficient, current and traceable.
Assessment reports and evidence can themselves contain highly sensitive security information and should be appropriately protected.
Assessment frequency should be based on risk, criticality, change, requirements and previous findings rather than assuming every control needs the same schedule.
Continuous monitoring means maintaining ongoing awareness at a frequency sufficient to support risk-based decisions. It does not mean every control must literally be tested every second.
Point-in-time testing provides assurance about a particular period or state, while ongoing monitoring helps detect changes between formal assessments.
Material changes such as major releases, migrations, incidents or new threats can trigger reassessment before the next scheduled review.
Automated assessment is useful for repeatable, scalable checks, while manual assessment remains important where context and judgement are required.
False positives report problems that are not present.
False negatives fail to identify real problems.
"No findings" does not automatically mean "no risk."
Each testing method has limitations, and conclusions should not extend beyond what the evidence can actually demonstrate.
Higher-risk systems can justify greater assessment depth, coverage, frequency and independence.
Different assessment techniques can complement one another because they identify different types of weakness.
Finally, the assessment strategy itself should be validated.
A technically perfect test of the wrong scope, wrong control or wrong threat can still produce poor assurance.
The central CISSP principle is: define the assurance objective, establish the scope, select risk-appropriate methods, gather credible evidence and confirm that the resulting strategy is sufficient to support the required risk decision.
📚 Sources & Further Reading Assessment, testing and continuous-monitoring references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-53A Rev. 5 - Assessing Security and Privacy Controls
View NIST control-assessment guidance - NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment
View NIST testing and assessment guidance - NIST SP 800-37 Rev. 2 - Risk Management Framework
View the NIST Risk Management Framework - NIST SP 800-137 - Information Security Continuous Monitoring
View NIST continuous-monitoring guidance - NIST SP 800-137A - Assessing Information Security Continuous Monitoring Programs
View NIST ISCM assessment guidance