Cleaned up Literature folder

Corpus/ISMS/Policy examples/Cloud Service Approval Process.md

@@ -0,0 +1,290 @@
+# Cloud Service Approval Process
+
+This comprehensive cloud service approval process provides a structured, rigorous approach to evaluating and implementing cloud services. It balances thorough risk management with the need for technological innovation and operational efficiency.
+
+The process is designed to be:
+
+- Transparent
+- Comprehensive
+- Flexible
+- Collaborative
+
+## 1. Initial Assessment Stage
+
+### 1.1 Preliminary Evaluation Form
+
+Employees must complete a comprehensive initial assessment:
+
+- Detailed business need justification
+- Specific problem the service will solve
+- Current workaround or existing solution limitations
+- Estimated productivity or efficiency gains
+- Anticipated user base within the organization
+
+### 1.2 Initial Screening Criteria
+
+Mandatory initial checks:
+
+- Alignment with organizational strategic objectives
+
+- Compatibility with existing IT infrastructure
+
+- Preliminary compliance with data protection regulations
+
+- Basic security feature assessment
+
+  
+
+## 2. Detailed Risk Assessment
+
+  
+
+### 2.1 Security Evaluation Checklist
+
+Comprehensive security review including:
+
+- Data encryption standards (at rest and in transit)
+
+- Authentication mechanisms
+
+- Access control capabilities
+
+- Compliance certifications (GDPR, HIPAA, etc.)
+
+- Data residency and sovereignty details
+
+- Vendor security history and reputation
+
+  
+
+### 2.2 Financial and Operational Analysis
+
+Evaluation of:
+
+- Total cost of ownership
+
+- Scalability options
+
+- Integration capabilities
+
+- Service level agreements (SLAs)
+
+- Exit strategy and data portability
+
+- Long-term vendor viability
+
+  
+
+## 3. Formal Review Process
+
+  
+
+### 3.1 Review Committee Composition
+
+Cross-functional review team including:
+
+- IT Security Representative
+
+- Data Protection Officer
+
+- Finance Representative
+
+- Department Head
+
+- Compliance Officer
+
+  
+
+### 3.2 Detailed Review Stages
+
+1. Initial document review
+
+2. Vendor presentation and Q&A
+
+3. Technical demonstration
+
+4. Reference and background check
+
+5. Comprehensive risk scoring
+
+  
+
+## 4. Technical Evaluation
+
+  
+
+### 4.1 Technical Architecture Review
+
+Comprehensive technical assessment:
+
+- API and integration capabilities
+
+- Performance benchmarking
+
+- Compatibility testing
+
+- Security penetration testing
+
+- Data migration potential
+
+- Interoperability assessment
+
+  
+
+### 4.2 Technical Validation Criteria
+
+- Minimum security score threshold
+
+- Compliance with organizational technical standards
+
+- Minimal disruption to existing systems
+
+- Scalable and future-proof architecture
+
+  
+
+## 5. Compliance and Legal Verification
+
+  
+
+### 5.1 Regulatory Compliance Check
+
+Verification of:
+
+- Data protection regulations
+
+- Industry-specific compliance requirements
+
+- International data transfer regulations
+
+- Terms of service legal review
+
+  
+
+### 5.2 Data Handling Assessment
+
+Detailed examination of:
+
+- Data ownership clauses
+
+- Information sharing policies
+
+- User data management practices
+
+- Breach notification protocols
+
+  
+
+## 6. Decision-Making Framework
+
+  
+
+### 6.1 Risk Scoring Matrix
+
+Quantitative evaluation across dimensions:
+
+- Security risk (0-10 scale)
+
+- Compliance risk (0-10 scale)
+
+- Operational impact (0-10 scale)
+
+- Financial implications (0-10 scale)
+
+  
+
+### 6.2 Approval Thresholds
+
+- Total score requirements
+
+- Mandatory mitigation for high-risk areas
+
+- Conditional approval mechanisms
+
+  
+
+## 7. Implementation and Monitoring
+
+  
+
+### 7.1 Pilot Implementation
+
+- Limited initial deployment
+
+- Controlled user group testing
+
+- Continuous monitoring
+
+- Performance and security validation
+
+  
+
+### 7.2 Ongoing Compliance Monitoring
+
+- Quarterly security reassessment
+
+- Annual comprehensive review
+
+- Continuous vendor performance tracking
+
+  
+
+## 8. Documentation and Governance
+
+  
+
+### 8.1 Comprehensive Documentation
+
+- Detailed approval documentation
+
+- Risk mitigation strategies
+
+- Implementation plan
+
+- Ongoing monitoring protocol
+
+  
+
+### 8.2 Knowledge Management
+
+- Update organizational cloud service catalog
+
+- Share learning and insights
+
+- Maintain vendor performance records
+
+  
+
+## 9. Rejection and Appeal Process
+
+  
+
+### 9.1 Rejection Notification
+
+- Detailed explanation of decision
+
+- Specific improvement recommendations
+
+- Alternative solution suggestions
+
+  
+
+### 9.2 Appeal Mechanism
+
+- Formal appeal process
+
+- Additional information submission
+
+- Secondary review option
+
+  
+
+## Appendices
+
+- Detailed Evaluation Form Template
+
+- Risk Assessment Scoring Rubric
+
+- Compliance Verification Checklist
+
+- Vendor Performance Tracking Template

Corpus/ISMS/Policy examples/Cloud Service Employee Guidelines.md

@@ -0,0 +1,374 @@
+# Employee Guidelines for Cloud Service
+
+  
+
+These guidelines provide a comprehensive, employee-centric approach to cloud service management. The framework emphasizes:
+
+  
+
+Collaborative decision-making
+
+Robust security practices
+
+Continuous learning
+
+Organizational risk management
+
+  
+
+The guidelines position the IT department as a consultative partner, supporting employees through the entire cloud service lifecycle.
+
+  
+  
+
+## 1. Identification of Need
+
+  
+
+### 1.1 Initial Assessment
+
+Before seeking a cloud service, employees must:
+
+- Clearly define the specific business problem
+
+- Confirm no existing internal solution exists
+
+- Understand the precise requirements
+
+- Consult with team members about potential solutions
+
+  
+
+### 1.2 Preliminary Consultation
+
+- Schedule an initial discussion with IT department
+
+- Prepare a brief outlining:
+
+* Current workflow challenges
+
+* Desired functionality
+
+* Expected outcomes
+
+* Potential user group
+
+  
+
+## 2. Pre-Selection Research
+
+  
+
+### 2.1 Initial Exploration
+
+Employees should:
+
+- Conduct initial market research
+
+- Identify 3-5 potential cloud service solutions
+
+- Gather preliminary information about:
+
+* Core features
+
+* Pricing models
+
+* Basic security capabilities
+
+* User reviews and reputation
+
+  
+
+### 2.2 Preliminary IT Consultation
+
+- Share research findings with IT department
+
+- Seek initial guidance on potential solutions
+
+- Understand organizational technology landscape
+
+- Discuss integration possibilities
+
+  
+
+## 3. Detailed Evaluation
+
+  
+
+### 3.1 Comprehensive Assessment Criteria
+
+Evaluate potential services against:
+
+- Security capabilities
+
+- Data protection mechanisms
+
+- Compliance requirements
+
+- Integration potential
+
+- Total cost of ownership
+
+- Scalability
+
+- User experience
+
+  
+
+### 3.2 Documentation Requirements
+
+Prepare a detailed evaluation document including:
+
+- Detailed feature comparison
+
+- Potential risks and mitigations
+
+- Business case justification
+
+- Expected return on investment
+
+- Proposed implementation strategy
+
+  
+
+## 4. Approval Process
+
+  
+
+### 4.1 Formal Submission
+
+Submit a comprehensive proposal to IT department:
+
+- Completed evaluation document
+
+- Proposed solution
+
+- Detailed implementation plan
+
+- Risk mitigation strategies
+
+  
+
+### 4.2 Collaborative Review
+
+- Participate in review meetings
+
+- Provide additional context
+
+- Be prepared to discuss alternatives
+
+- Collaborate on refining the proposal
+
+  
+
+## 5. Onboarding and Implementation
+
+  
+
+### 5.1 Pre-Implementation Preparation
+
+Before service activation:
+
+- Attend mandatory training sessions
+
+- Complete security awareness briefing
+
+- Understand data handling protocols
+
+- Review service-specific guidelines
+
+  
+
+### 5.2 Initial Configuration
+
+Employees must:
+
+- Work with IT to configure service
+
+- Implement recommended security settings
+
+- Create service-specific access protocols
+
+- Document initial configuration
+
+  
+
+## 6. Ongoing Usage Guidelines
+
+  
+
+### 6.1 Data Handling
+
+Strict protocols for:
+
+- Protecting sensitive information
+
+- Avoiding unauthorized data sharing
+
+- Using only approved data fields
+
+- Maintaining confidentiality
+
+  
+
+### 6.2 Access Management
+
+- Use only authorized accounts
+
+- Implement strong authentication
+
+- Regularly review access permissions
+
+- Immediately report suspicious activities
+
+  
+
+### 6.3 Continuous Compliance
+
+- Stay informed about service updates
+
+- Attend periodic compliance training
+
+- Participate in regular security reviews
+
+- Report potential compliance risks
+
+  
+
+## 7. Performance Monitoring
+
+  
+
+### 7.1 Usage Tracking
+
+- Maintain usage logs
+
+- Participate in periodic reviews
+
+- Provide feedback on service effectiveness
+
+- Report performance issues promptly
+
+  
+
+### 7.2 Continuous Improvement
+
+- Suggest potential enhancements
+
+- Participate in optimization discussions
+
+- Share insights about workflow improvements
+
+  
+
+## 8. Decommissioning Process
+
+  
+
+### 8.1 Preliminary Evaluation
+
+Determine decommissioning need based on:
+
+- Changing business requirements
+
+- Performance issues
+
+- Cost-effectiveness
+
+- Technological obsolescence
+
+  
+
+### 8.2 Formal Decommissioning Procedure
+
+Steps for responsible service retirement:
+
+1. Notify IT department
+
+2. Conduct comprehensive data audit
+
+3. Develop data migration strategy
+
+4. Execute secure data extraction
+
+5. Confirm complete data removal
+
+6. Formally terminate service agreement
+
+  
+
+### 8.3 Knowledge Transfer
+
+- Document lessons learned
+
+- Share insights with team
+
+- Update organizational knowledge base
+
+  
+
+## 9. Potential Consequences of Non-Compliance
+
+  
+
+### 9.1 Risks of Unauthorized Usage
+
+- Potential security breaches
+
+- Compliance violations
+
+- Financial risks
+
+- Disciplinary actions
+
+  
+
+### 9.2 Escalation Process
+
+- Initial warning
+
+- Mandatory retraining
+
+- Potential access restrictions
+
+- Performance management implications
+
+  
+
+## 10. Support and Resources
+
+  
+
+### 10.1 IT Department Support
+
+- Dedicated support channels
+
+- Quick response mechanisms
+
+- Continuous guidance
+
+- Regular training opportunities
+
+  
+
+### 10.2 Additional Resources
+
+- Internal knowledge base
+
+- Regular workshops
+
+- Peer support networks
+
+- Comprehensive documentation
+
+  
+
+## Appendices
+
+- Evaluation Form Template
+
+- Risk Assessment Checklist
+
+- Approved Services List
+
+- Contact Information for Support

Corpus/ISMS/Policy examples/Cloud Service Risk Assessment Guide.md

@@ -0,0 +1,187 @@
+# Cloud Service Risk Assessment Guide
+
+  
+
+## Purpose
+
+This guide provides a simple, straightforward approach for non-technical employees to evaluate the safety and appropriateness of cloud services before use.
+
+  
+
+## The 10-Step Risk Assessment Checklist
+
+  
+
+### 1. Identify the Business Need
+
+- Clearly define why you need this service
+
+- Ask yourself: "Does this solve a specific work problem?"
+
+- Confirm no existing internal solution exists
+
+- Ensure the need is legitimate and work-related
+
+  
+
+### 2. Check Data Protection Basics
+
+- Identify what type of data you'll be storing
+
+- Assess sensitivity (personal, confidential, or public information)
+
+- Ask the provider: "How do you protect my data?"
+
+- Look for clear, understandable data protection statements
+
+  
+
+### 3. Verify Vendor Credibility
+
+- Research the company's reputation
+
+- Check how long they've been in business
+
+- Look for customer reviews from similar organizations
+
+- Investigate any past security incidents
+
+  
+
+### 4. Understand Data Ownership
+
+- Read the terms of service carefully
+
+- Confirm who owns the data you upload
+
+- Check if the vendor can use your data
+
+- Ensure you can retrieve or delete your data easily
+
+  
+
+### 5. Assess Access and Authentication
+
+- Evaluate login security features
+
+- Check if multi-factor authentication is available
+
+- Understand how access can be controlled
+
+- Verify you can manage user permissions
+
+  
+
+### 6. Compliance Check
+
+- Confirm the service meets relevant regulations
+
+- Check for industry-specific certifications
+
+- Verify data storage locations
+
+- Ensure compliance with organizational policies
+
+  
+
+### 7. Financial and Operational Transparency
+
+- Understand full cost implications
+
+- Check for hidden fees
+
+- Assess service reliability
+
+- Review service level agreements (SLAs)
+
+  
+
+### 8. Integration and Exit Strategy
+
+- Determine how the service fits with existing tools
+
+- Check data migration capabilities
+
+- Understand process for leaving the service
+
+- Ensure easy data export options
+
+  
+
+### 9. Consult IT Support
+
+- Share your findings with the IT department
+
+- Request a quick review
+
+- Be open to alternative solutions
+
+- Seek guidance on potential risks
+
+  
+
+### 10. Document and Review
+
+- Complete a brief risk assessment form
+
+- Document your justification
+
+- Keep records of your evaluation
+
+- Plan for periodic service reassessment
+
+  
+
+## Risk Assessment Outcome
+
+  
+
+### Low Risk Indicators
+
+- Clear business need
+
+- Strong data protection
+
+- Reputable vendor
+
+- Transparent terms
+
+- Compliance with policies
+
+  
+
+### High Risk Warning Signs
+
+- Vague data protection
+
+- Unclear ownership terms
+
+- Limited authentication
+
+- Compliance concerns
+
+- Unexpected costs
+
+  
+
+## Appendix: Quick Reference Checklist
+
+- ☐ Business need validated
+
+- ☐ Data protection verified
+
+- ☐ Vendor credibility checked
+
+- ☐ Data ownership understood
+
+- ☐ Access controls assessed
+
+- ☐ Compliance confirmed
+
+- ☐ Costs transparent
+
+- ☐ Integration potential evaluated
+
+- ☐ IT department consulted
+
+- ☐ Documentation completed

Corpus/ISMS/Policy examples/Cloud Service Risk Mitigation Roadmap.md

@@ -0,0 +1,335 @@
+# Cloud Service Risk Mitigation Roadmap
+
+  
+
+This comprehensive roadmap provides a structured, systematic approach to managing the risk associated with unmandated cloud services. The strategy balances:
+
+  
+
+Immediate risk mitigation
+
+Long-term governance
+
+Employee empowerment
+
+Organizational security
+
+  
+
+Key strengths of the approach include:
+
+  
+
+Detailed risk prioritization
+
+Phased implementation
+
+Continuous monitoring
+
+Emphasis on employee education
+
+  
+
+## 1. Discovery and Inventory Phase
+
+  
+
+### 1.1 Comprehensive Service Mapping
+
+- Conduct a full organizational audit to identify all existing cloud services
+
+- Methods of discovery:
+
+* Network traffic analysis
+
+* Employee surveys
+
+* Expense report review
+
+* Active directory and authentication log analysis
+
+* Collaboration with department heads
+
+  
+
+### 1.2 Detailed Inventory Creation
+
+For each identified service, document:
+
+- Service name and provider
+
+- Department of origin
+
+- Primary users
+
+- Data types processed
+
+- Current access mechanisms
+
+- Frequency of use
+
+- Account ownership details
+
+- Potential business criticality
+
+  
+
+## 2. Risk Prioritization Framework
+
+  
+
+### 2.1 Risk Scoring Methodology
+
+Develop a multi-dimensional risk assessment matrix:
+
+  
+
+#### Risk Dimensions (0-10 scale)
+
+1. **Data Sensitivity**
+
+- Personal identifiable information
+
+- Confidential organizational data
+
+- Regulatory compliance exposure
+
+  
+
+2. **Security Vulnerability**
+
+- Authentication mechanisms
+
+- Encryption standards
+
+- Vendor security track record
+
+- Potential data exposure risks
+
+  
+
+3. **Operational Impact**
+
+- Business criticality
+
+- User dependency
+
+- Workflow integration
+
+- Potential disruption risk
+
+  
+
+4. **Compliance Exposure**
+
+- Regulatory requirements
+
+- Data protection laws
+
+- Industry-specific regulations
+
+- Cross-border data transfer risks
+
+  
+
+### 2.2 Prioritization Matrix
+
+Calculate composite risk score:
+
+- High Risk (Score 27-40): Immediate Action Required
+
+- Medium Risk (Score 15-26): Planned Mitigation
+
+- Low Risk (Score 0-14): Monitor and Validate
+
+  
+
+## 3. Immediate Mitigation Strategies
+
+  
+
+### 3.1 High-Risk Services
+
+Urgent intervention steps:
+
+- Immediate access restrictions
+
+- Temporary service isolation
+
+- Rapid data migration
+
+- Emergency account consolidation
+
+- Potential service discontinuation
+
+  
+
+### 3.2 Medium-Risk Services
+
+Structured remediation approach:
+
+- Comprehensive security review
+
+- Implement additional access controls
+
+- Develop migration strategy
+
+- Negotiate improved terms with vendors
+
+- Create standardized usage guidelines
+
+  
+
+### 3.3 Low-Risk Services
+
+Monitoring and validation:
+
+- Periodic security reassessment
+
+- User necessity verification
+
+- Cost-benefit analysis
+
+- Potential consolidation opportunities
+
+  
+
+## 4. Implementation Roadmap
+
+  
+
+### 4.1 Phased Approach
+
+1. **Phase 1 (0-30 days)**
+
+- Complete initial inventory
+
+- Identify and isolate high-risk services
+
+- Develop emergency mitigation plan
+
+- Begin stakeholder communication
+
+  
+
+2. **Phase 2 (31-90 days)**
+
+- Implement access controls
+
+- Migrate critical data
+
+- Develop standardized service selection process
+
+- Conduct comprehensive security training
+
+  
+
+3. **Phase 3 (91-180 days)**
+
+- Complete service rationalization
+
+- Implement new governance framework
+
+- Develop long-term cloud service strategy
+
+- Establish continuous monitoring mechanism
+
+  
+
+## 5. Governance and Compliance
+
+  
+
+### 5.1 Centralized Management Approach
+
+- Create a Cloud Service Governance Committee
+
+- Develop comprehensive cloud service policy
+
+- Implement centralized procurement process
+
+- Establish ongoing review mechanisms
+
+  
+
+### 5.2 Continuous Monitoring
+
+- Quarterly comprehensive reviews
+
+- Automated discovery and tracking tools
+
+- Regular risk reassessment
+
+- Adaptive policy development
+
+  
+
+## 6. Employee Engagement and Education
+
+  
+
+### 6.1 Communication Strategy
+
+- Transparent communication about risks
+
+- Clear explanation of mitigation steps
+
+- Provide alternative, approved solutions
+
+- Create supportive transition environment
+
+  
+
+### 6.2 Training and Support
+
+- Comprehensive security awareness training
+
+- Workshops on responsible technology adoption
+
+- Develop internal knowledge base
+
+- Create support channels for technology selection
+
+  
+
+## 7. Financial Considerations
+
+  
+
+### 7.1 Cost Analysis
+
+- Consolidate existing service subscriptions
+
+- Negotiate enterprise-level agreements
+
+- Identify potential cost savings
+
+- Develop budget for approved services
+
+  
+
+### 7.2 Investment in Governance
+
+- Allocate resources for:
+
+* Monitoring tools
+
+* Training programs
+
+* Governance infrastructure
+
+* Security enhancement
+
+  
+
+## Appendices
+
+- Detailed Risk Assessment Template
+
+- Service Inventory Spreadsheet
+
+- Communication Plan
+
+- Training Materials
+
+- Governance Policy Draft

Corpus/ISMS/Policy examples/Drafting Policies.md

@@ -0,0 +1,6 @@
+# Drafting Policies
+
+[ISO_27002_2022_5.1_PE Policies for information security](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.1_PE%20Policies%20for%20information%20security.md)
+[Def_Sec_Handbook_Chapter_3](../../Literature/Defensive%20Security%20Handbook/Def_Sec_Handbook_Chapter_3.md)
+[DoD Cybersecurity Policy Chart webpage](https://csiac.org/resources/the-dod-cybersecurity-policy-chart/)
+[DoD Cybersecurity Policy Chart download](https://csiac.org/wp-content/uploads/2022/11/2022-11-21-csiac-dod-cybersecurity-policy-chart.pdf)

Corpus/ISMS/Policy examples/Drafting a Vendor and Product checklist.md

@@ -0,0 +1,27 @@
+# Drafting a Vendor and Product checklist
+
+Related: [Vendor security MoC](..//Vendor%20security%20MoC.md)
+
+ESCROW
+BOM
+
+From [ISO_27002_2022_5.19_PE Information security in supplier relationships](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.19_PE%20Information%20security%20in%20supplier%20relationships.md) (selection)
+- criteria and procedures for vendor selection, taking the sensitivity of products, services and the information they'll be working with into account. 
+- checking that the vendor has implemented adequate controls for information security, personnel security and physical security
+- processes and procedures the vendor needs to implement for implementing and terminating the product/service in your organization
+- continuity measures in case the vendor is no longer willing or able to supply its products or services
+- return of assets
+- the ownership of what has been developed during the relationship
+- continuation of non-disclosure/confidentiallity agreements
+
+From [ISO_27002_2022_5.21_PE Managing information security in the ICT supply chain](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.21_PE%20Managing%20information%20security%20in%20the%20ICT%20supply%20chain.md) (selection)
+
+- require that suppliers demand the same level of security for sub-contractors and product or component suppliers, as you demand of them
+- request a 'bill of materials' for third party software components they use
+- description of security functions in the product, and directions for the correct configuration thereof
+- rules for communicating issues and compromises in the supply chain
+- component lifecycle management, incl. availabilty risks and end-of-service
+- alternative suppliers, software and knowledge transfers
+
+
+

Corpus/ISMS/Policy examples/Dropbox Supplier Security Requirements.md

@@ -0,0 +1,105 @@
+Source: [Github](https://github.com/dropbox/vsmc/blob/master/model-contract.md)
+Retrieved: February 15, 2023
+
+# Dropbox Supplier Security Requirements
+
+These Supplier Security Requirements apply to Supplier when it provides services to Dropbox. Terms used here but not defined here are defined in the Agreement.
+
+
+## 1. Third Party Testing and Validation.
+
+### 1.1. General Testing.
+
+**a. Periodic Tests.** Supplier shall allow Dropbox, or Dropbox’s delegate, to periodically test the security of the Services. When testing Dropbox or its Delegate shall: (i) carefully conduct tests that are reasonably designed to safely uncover possible vulnerabilities without undue risk; and (ii) make commercially reasonable efforts to tailor the tests as needed to specifically achieve the purpose of the test.
+
+**b. Timing.**  Dropbox or its delegate may conduct the security tests in Section 1.1 at any time during the term of the Agreement. Dropbox will: (i) provide Supplier with reasonable notice prior to conducting the tests, (ii) promptly inform Supplier of any findings; and (iii) delay further disclosure until Supplier has had reasonable time to resolve issues identified in the findings.
+
+### 1.2. Vulnerability Disclosure Policy.
+
+**a. Generally.** Supplier shall publish a Vulnerability Disclosure Policy (“VDP”) on its public website. This VDP shall: (i) welcome arbitrary security research; (ii) include all internet facing assets in scope; (iii) provide safe harbor from CFAA and DMCA actions for all good faith research; and (iv) not place restrictions on disclosure. 
+
+**b. Contact and Service Level Agreement.** Supplier shall: (i) post a method by which the public can contact Supplier to report security vulnerabilities; and (ii) use best efforts to respond to these reported security vulnerabilities within a commercially reasonable period of time based on the severity and impact of the vulnerability.
+
+**c. Bug Bounty Program.** Supplier agrees that Dropbox may make deliverables or results of the Services subject to Dropbox’s Bug Bounty Program. Dropbox will notify Supplier of any material security-related vulnerabilities in the Services or deliverables identified through its Bug Bounty Program. Supplier understands that research and disclosures are governed by Dropbox's VDP, which requires good faith and responsible behavior by participants.
+
+### 1.3. Application and Network Penetration Testing.
+
+**a. Annual Testing.** Supplier shall, at least once per year, perform a suite of independent third-party tests. These tests will be performed upon: (i) the Services; (ii) all aspects of Supplier’s internet-facing perimeter; and (iii) Supplier’s internal corporate network and internal systems. Supplier will supply Dropbox with details of all third-party tests from the previous year, including names of third-party testers and number of person hours used.
+
+**b. Sharing Results.** Supplier shall, upon Dropbox’s request and under suitable non-disclosure obligations, share with Dropbox: (i) confirmation that the tests required by this Section 1.3 were performed; and (ii) the third party tests results from Sections 1.3(a)(i) and (ii) above.
+
+### 1.4. Fixing Issues.
+
+Supplier will fix all critical and high severity vulnerabilities that could affect the security of Dropbox Data, of which Supplier becomes aware, within sixty days of becoming aware of the vulnerability. If Supplier cannot fix the vulnerability within sixty days, Supplier will promptly inform Dropbox, including all details of the risk to Dropbox arising from Supplier’s inability to fix the vulnerability.
+
+## 2. Technical Security Measures.
+
+### 2.1. Transport Encryption.
+
+Supplier will maintain an SSL Labs rating (please see https://www.ssllabs.com) of at least “A” for any external website used to store or access Dropbox data. If Supplier’s rating falls below “A,” Supplier will: (a) notify Dropbox if this rating is below “A” for three months; and (b) have three months from the date it notifies Dropbox within which to increase its rating back to an “A.”
+
+### 2.2. Google G Suite Authentication Integration.
+
+If the Services include a SaaS service, Supplier will integrate the Services with Google G Suite authentication for Dropbox’s login needs. This Google G Suite authentication integration will be the only method by which Dropbox users log in to the Service.
+
+### 2.3. Multifactor Authentication.
+
+Supplier will use a multifactor authentication (“MFA”) login solution for the Services, provided that text or phone call are not acceptable factors. MFA must be used for: (a) any VPN connections into the Supplier’s internal networks; (b) any connections into Supplier’s production environment; (c) Supplier’s e-mail, if it can be accessed from the internet; and (d) any services Supplier uses that contain Dropbox Data.
+
+### 2.4. Patching.
+
+Supplier will promptly apply any high or critical severity security patches to their production servers, endpoints, and endpoint management systems. 
+
+### 2.5. Detection and Alerting.
+
+Supplier will proactively monitor, detect, and alert its internal security team regarding suspicious or malicious activity within Supplier’s production and corporate environments. 
+
+### 2.6. Scanning.
+
+Supplier will run regular automated scans against their internet facing perimeter, production perimeter, and internal network. Supplier will promptly fix high and critical severity findings.
+
+### 2.7. Environment Separation and Access.
+
+Supplier will maintain a boundary between its corporate and production environments. Supplier will maintain controls gating access into the production boundary, and Supplier will only provide production environment access to employees or contractors who must maintain the production environment.
+
+## 3. Policy and Compliance.
+
+### 3.1. Security Incidents.
+
+**a. Notification and Timing.** Supplier will notify Dropbox in writing of any Security Incident within seventy-two hours of Supplier becoming aware of the Security Incident. This notification is required even if Supplier has not conclusively established the nature or extent of the Security Incident. Supplier will not communicate with any third party regarding a Security Incident except as specified by Dropbox, or as required by law.
+
+**b. Required Information.** Supplier’s Security Incident notification will describe the known details of the incident, the status of Supplier’s investigation, and, if applicable, the potential number of persons affected. Supplier will be solely responsible for all costs associated with any security breach; which includes, if applicable, for notices to and credit monitoring for affected individuals.
+
+### 3.2. Compliance Certification.
+
+Supplier shall: (a) maintain compliance with at least one of the following: (i) SSAE 16/SOC 1; (ii) SOC 2; or (iii) ISO 27001; (b) provide audit reports or evidence of these certifications to Dropbox upon request; and (c) ensure that all Supplier subcontractors or third party delegates adhere to the same standards. 
+
+### 3.3. Secure Development Lifecycle.
+
+Supplier shall maintain and follow a Secure Development Lifecycle (“SDL”) for the development of its products and services. Supplier’s SDL will be supported by at least one full time security engineer. Supplier will provide Dropbox a copy of its SDL policy and process documents upon request.
+
+### 3.4. Supporting Information.
+
+Upon Dropbox’s request, Supplier will provide its policy and process documents relating to any of the security controls referenced in these Security Requirements to Dropbox.
+
+### 3.5. Handling of Dropbox Data.
+
+Supplier will not move Dropbox Data from Supplier’s production environment unless specifically asked to do so by Dropbox. Specifically, Dropbox Data must not be downloaded to phones or laptops, and must not be shared with third parties. Supplier will delete Dropbox Data permanently upon Dropbox’s request.
+
+## 4. Modifications.
+
+Dropbox may periodically update these Security Requirements by posting a new version. If Dropbox changes these Security Requirements in a manner that materially increases Supplier’s obligations, Dropbox will notify Supplier, and Supplier will have ninety days within which to object to the changes. If Supplier does not object within this timeframe, Supplier agrees to comply with the modified Security Requirements. If Supplier objects within this time frame, and Supplier and Dropbox cannot resolve the objection within thirty days, then Dropbox may terminate the Agreement immediately upon written notice to Supplier.
+
+  
+
+## 5. Definitions.
+
+“Agreement” means the executed Agreement between Supplier and Dropbox.
+
+“Dropbox Data” means any data that is provided to Supplier by Dropbox or on behalf of Dropbox.
+
+“Security Incident” means any: (i) breach or suspected breach of the security of the Services or the systems used to provide the Services that may have resulted in the compromise of Dropbox Data; or (ii) other unauthorized access to or use of Dropbox Data, or Supplier's reasonable belief that access or use may have occurred.
+
+“Services” means the products or services provided by Supplier to Dropbox.
+
+“Suppliers” means those vendors who provide services to Dropbox.

Corpus/ISMS/Policy examples/Example introduction for an Internal Privacy Policy.md

@@ -0,0 +1,19 @@
+From Ultimaker’s Internal Privacy Policy, p.3:
+
+“The Policy is based on the GDPR, which sets out seven principles in Article 5. These are:
+1. Lawfulness, fairness, and transparency
+2. Purpose limitation
+3. Data minimalization
+4. Accuracy
+5. Storage limitation
+6. Integrity and confidentiality (security)
+7. Accountability
+
+To ensure an appropriate level of data protection, we are committed to (p4):
+1. Restrict and monitor access to sensitive data
+2. Develop transparent data collection procedures
+3. Train employees in online privacy and security measures
+4. Build secure networks to protect online data from cyberattacks
+5. Establish clear procedures for reporting privacy breaches or data misuse
+6. Include contract clauses or communicate statements on how we handle data
+7. Establish data protection practices (document shredding, secure locks, data encryption, frequent backups, access authorization etc.)

Corpus/ISMS/Policy examples/Key Topics for a policy on handling classified information.md

@@ -0,0 +1,38 @@
+# Key Topics for a policy on handling classified information
+
+A comprehensive policy on handling classified information should address the following key topics to ensure its security and confidentiality:
+
+1. Classification Levels and Criteria:
+ * Definition of classification levels: Clearly define the different levels of classification (e.g., Top Secret, Secret, Confidential) and their corresponding sensitivity.
+ * Classification criteria: Establish specific criteria for classifying information, such as potential damage to national security, economic interests, or other critical concerns.
+ * Classification authority: Specify who has the authority to classify and declassify information.
+
+2. Access Controls:
+ * Need-to-know principle: Enforce the principle that access to classified information should be granted only to individuals with a genuine need to know.
+ * Security clearances: Implement a rigorous security clearance process to assess the trustworthiness and reliability of personnel handling classified information.
+ * Access controls: Establish robust access controls, including physical, logical, and administrative measures, to restrict access to authorized individuals.
+
+3. Handling and Storage:
+ * Secure handling procedures: Define procedures for handling classified information, such as proper storage, transportation, and destruction.
+ * Secure storage facilities: Specify requirements for secure storage facilities, including controlled access, surveillance, and environmental controls.
+ * Marking and labeling: Mandate clear and consistent marking and labeling of classified documents and electronic media.
+
+4. Communication and Dissemination:
+ * Authorized communication channels: Specify authorized channels for communicating classified information, such as secure networks, encrypted email, or secure physical delivery.
+ * Restrictions on dissemination: Limit the dissemination of classified information to authorized individuals and organizations.
+ * Foreign disclosure: Establish guidelines for disclosing classified information to foreign entities, including appropriate approvals and safeguards.
+
+5. Incident Response:
+ * Incident reporting: Define procedures for reporting security incidents involving classified information, including unauthorized access, loss, or compromise.
+ * Incident response plan: Develop a comprehensive incident response plan to address security breaches, including containment, investigation, and recovery measures.
+ * Damage assessment: Establish procedures for assessing the potential damage caused by a security incident.
+
+6. Training and Awareness:
+ * Mandatory training: Require all personnel with access to classified information to undergo regular security awareness and training.
+ * Training content: Cover topics such as classification levels, handling procedures, security threats, and incident response.
+ * Continuous education: Implement a program of continuous education to keep personnel updated on evolving security threats and best practices.
+
+7. Monitoring and Auditing:
+ * Regular monitoring: Conduct regular monitoring and auditing of systems and processes to identify and address security vulnerabilities.
+ * Access reviews: Periodically review and update access permissions to ensure continued need-to-know.
+ * Security audits: Conduct independent security audits to assess compliance with the policy and identify areas for improvement.

Corpus/ISMS/Policy examples/Shadow IT Policy for Responsible Technology Adoption.md

@@ -0,0 +1,241 @@
+# Shadow IT Policy for Responsible Technology Adoption
+
+  
+
+## 1. Purpose and Principles
+
+  
+
+### 1.1 Policy Objective
+
+This policy aims to:
+
+- Empower employees to make informed technology choices
+
+- Protect the organization's information security
+
+- Foster a culture of responsible technology adoption
+
+- Align technological innovation with organizational goals
+
+  
+
+### 1.2 Guiding Principles
+
+- Transparency
+
+- Collaboration
+
+- Continuous Learning
+
+- Shared Responsibility
+
+- Risk-Aware Decision Making
+
+  
+
+## 2. Employee Responsibilities
+
+  
+
+### 2.1 Technology Evaluation Process
+
+Employees must:
+
+- Conduct a preliminary assessment of any proposed cloud service or software
+
+- Complete a standardized Technology Evaluation Form before implementing new tools
+
+- Demonstrate how the proposed technology:
+
+* Addresses a specific business need
+
+* Improves operational efficiency
+
+* Complies with organizational standards
+
+  
+
+### 2.2 Risk Assessment
+
+Prior to adopting any new technology, employees must evaluate:
+
+- Data protection capabilities
+
+- Compliance with relevant regulations
+
+- Potential security vulnerabilities
+
+- Integration with existing systems
+
+- Total cost of ownership
+
+  
+
+### 2.3 Mandatory Consultation
+
+Employees must:
+
+- Consult with the IT department before implementing new technologies
+
+- Provide a comprehensive justification for the proposed solution
+
+- Participate in a collaborative review process
+
+- Be open to alternative recommendations
+
+  
+
+## 3. IT Department's Consultative Role
+
+  
+
+### 3.1 Support Framework
+
+The IT department will:
+
+- Provide guidance, not gatekeeping
+
+- Offer rapid response to technology adoption requests
+
+- Maintain a current catalog of approved and recommended tools
+
+- Develop clear, accessible guidelines for technology selection
+
+  
+
+### 3.2 Consultation Process
+
+IT will:
+
+- Review technology proposals within 5 business days
+
+- Provide constructive feedback
+
+- Suggest security and integration improvements
+
+- Collaborate on finding optimal solutions
+
+  
+
+### 3.3 Ongoing Support
+
+- Offer regular training on technology evaluation
+
+- Maintain an internal knowledge base of approved and vetted tools
+
+- Provide templates and checklist for technology assessment
+
+  
+
+## 4. Approval and Documentation
+
+  
+
+### 4.1 Documentation Requirements
+
+Employees must document:
+
+- Business justification
+
+- Detailed risk assessment
+
+- Proposed implementation strategy
+
+- Data handling and protection measures
+
+  
+
+### 4.2 Approval Workflow
+
+1. Employee completes Technology Evaluation Form
+
+2. Initial review by immediate supervisor
+
+3. Consultation with IT department
+
+4. Final approval by department head and IT representative
+
+  
+
+## 5. Continuous Improvement
+
+  
+
+### 5.1 Periodic Review
+
+- Quarterly review of adopted technologies
+
+- Annual policy and process refinement
+
+- Feedback collection from employees
+
+  
+
+### 5.2 Learning and Development
+
+- Regular workshops on technology trends
+
+- Sharing of best practices
+
+- Recognition of innovative technology solutions
+
+  
+
+## 6. Consequences of Non-Compliance
+
+  
+
+### 6.1 Potential Actions
+
+- Temporary suspension of unauthorized technology use
+
+- Mandatory retraining
+
+- Potential disciplinary action for repeated violations
+
+  
+
+### 6.2 Escalation Process
+
+- Written warning
+
+- Performance review impact
+
+- Potential removal of technology adoption privileges
+
+  
+
+## 7. Technology Adoption Incentives
+
+  
+
+### 7.1 Recognition Program
+
+- Acknowledge employees who:
+
+* Identify cost-effective solutions
+
+* Demonstrate thorough risk assessment
+
+* Innovate through responsible technology adoption
+
+  
+
+### 7.2 Career Development
+
+- Include technology evaluation skills in performance metrics
+
+- Create opportunities for technology champions
+
+  
+
+## Appendices
+
+- Technology Evaluation Form Template
+
+- Approved Tools List
+
+- Risk Assessment Checklist
+
+- Compliance Guideline References

Corpus/ISMS/Policy examples/Voorbeeld van een release script.md

@@ -0,0 +1,38 @@
+*Voorbeeld van een artefact voor [A8.25 Secure development life cycle](../../MoCs/ISO_27002_2022_8.25_MoC%20Secure%20development%20life%20cycle.md)*
+
+Bron: Normity
+
+Omdat we werken met Kanban bepalen we zelf wanneer we een release gaan laten plaatsvinden. Dit doen we eventueel in overleg met de stakeholders en wordt per release bepaald. Gemiddeld genomen doen we dit eenmaal per 4 weken met regelmatige tussentijdse kleinere releases. De PO bepaalt uiteindelijk wanneer de release plaatsvindt. Hotfixes volgen deze procedure niet, maar hebben een eigen release proces. Omdat deze over het algemeen zeer klein zijn, wordt dit van geval tot geval bepaald.
+
+Hoe gaat zo'n release nu in zijn werk?
+
+- Zorg dat alle issues die meegaan gemerged zijn naar Develop branch
+
+- Doe een laatste controle op de code:
+	- Hebben alle JSON taalbestanden hetzelfde aantal regels
+	- Zijn er geen dumps of aborts meer te vinden in de code
+	- Draai vertalingenControleren.cfm of vertalingen ontbreken
+
+- Maak de nieuwe Master branch
+
+- Controleer nu eerst of de benodigde omgevingen beschikbaar zijn:
+	- SQL Server toegang
+	- Royal TS toegang
+
+- Zorg er nu voor dat de code online komt te staan:
+	- Draai alle scripts in de SQL Server omgeving
+	- Doe een pull van de code op de server
+	- Herstart Normity (zowel demo als normity docker)
+	- Doe een korte controle
+
+- Is het een nieuw versienummer? Doe dan:
+	- Doorloop de stories uit de release
+	- Stel de release notes op
+	- Voeg die toe via de beheerschermen
+
+- Tenslotte nog even de code klaarmaken voor de nieuwe release:
+	- Maak Jira board gereed voor nieuwe release
+	- Verwijder overbodige feature branches
+	- Verplaats de bijbehorende SQL bestanden van _assets/scripts/features naar _assets/scripts/x.x.x/
+	- Maak een nieuwe branch aan voor de nieuwe release
+	- Wijzig eventueel het versienummer in Application.cfc

Corpus/ISMS/Policy examples/Vulnerability Disclosure Policy.md

@@ -0,0 +1,5 @@
+Having a permissive vulnerability disclosure policy (VDP) encourages security research, and is a key characteristic of a good, mature security program. It encourages transparency.
+
+For you as a vendor, it enhances [Vendor security MoC](../Vendor%20security%20MoC.md) towards your customers.
+As a customer, you may check for a VDP when creatingyour [Examples of vendor selection questionnaires](../../Information%20Security/Examples%20of%20vendor%20selection%20questionnaires.md).
+

Corpus/ISMS/Policy examples/WeWeb Security Pre-Launch Checklist.md

@@ -0,0 +1,105 @@
+# WeWeb Security Pre-Launch Checklist
+
+I've created a comprehensive security checklist that expands on each of your original items. The key principle throughout is that **security must be enforced server-side** - WeWeb (being a frontend no-code platform) can only provide the user interface, while your backend APIs and database must handle all the actual security enforcement.
+
+The most critical point is that you should never trust the client-side for security decisions. Even though WeWeb can hide UI elements or restrict navigation, a determined user could still make direct API calls to bypass these restrictions. That's why server-side validation and authorization are absolutely essential for each of these security measures.
+
+
+## ☐ Restrict User Access
+
+**What this means:** Limit who can access your application and specific features based on authentication status and user roles.
+
+**Implementation pointers:**
+- **Authentication Gates:** Set up proper login/logout flows using WeWeb's authentication workflows
+- **Protected Routes:** Configure page-level access restrictions in WeWeb's router settings
+- **Conditional Rendering:** Use WeWeb's conditional visibility settings to hide/show components based on user authentication status
+- **Session Management:** Implement proper session timeouts and renewal mechanisms
+- **Multi-factor Authentication:** Consider adding 2FA for sensitive applications
+- **IP Whitelisting:** For internal tools, restrict access by IP address ranges
+
+**WeWeb-specific tips:**
+- Use the built-in Auth0, Supabase, or Firebase authentication plugins
+- Set up global variables for user authentication state
+- Configure redirects for unauthenticated users to login pages
+
+---
+
+## ☐ Filter Sensitive Data Server-Side
+
+**What this means:** Never rely on client-side filtering to hide sensitive information. All data filtering must happen on your backend/API before sending to WeWeb.
+
+**Implementation pointers:**
+- **API Endpoint Security:** Create separate API endpoints for different user roles (e.g., `/api/admin/users` vs `/api/users`)
+- **Database Queries:** Use proper WHERE clauses and JOIN conditions to filter data at the database level
+- **Field Selection:** Only return necessary fields in API responses (avoid SELECT * queries)
+- **Data Masking:** For partially sensitive data (like phone numbers), mask on the server before sending
+- **Audit Logging:** Log all data access requests for security monitoring
+
+**WeWeb-specific tips:**
+- Configure your REST API or GraphQL collections with proper filtering parameters
+- Use WeWeb's data source authentication to pass user tokens to your backend
+- Set up different API collections for different user roles
+- Never store sensitive data in WeWeb's browser storage or global variables
+
+---
+
+## ☐ Enforce Access Control on User IDs
+
+**What this means:** Prevent users from accessing or modifying data belonging to other users by manipulating user IDs in requests.
+
+**Implementation pointers:**
+- **Server-Side Validation:** Always validate that the requesting user has permission to access the specified user ID
+- **Token-Based Authorization:** Use JWT tokens or similar to securely identify the current user
+- **Parameter Validation:** Never trust user IDs sent from the client - always cross-reference with authenticated session
+- **Resource Ownership Checks:** Verify that the authenticated user owns or has permission to access the requested resource
+- **Indirect Object References:** Use random tokens or UUIDs instead of sequential IDs where possible
+
+**WeWeb-specific tips:**
+- Pass authenticated user tokens in API headers, not as query parameters
+- Use WeWeb's user context variables to automatically include user IDs in API calls
+- Configure your backend to extract user ID from authenticated tokens, not from request parameters
+- Set up proper error handling for unauthorized access attempts
+
+---
+
+## ☐ Enforce Role-Based Permission Checks
+
+**What this means:** Implement a system where users can only perform actions and access resources appropriate to their assigned roles.
+
+**Implementation pointers:**
+- **Role Definition:** Clearly define roles (admin, user, moderator, etc.) and their associated permissions
+- **Permission Matrices:** Create a clear mapping of which roles can perform which actions
+- **Middleware Implementation:** Use backend middleware to check permissions before processing requests
+- **Granular Permissions:** Consider feature-level permissions (read, write, delete) rather than just role-based access
+- **Dynamic Role Assignment:** Allow for flexible role assignment and modification
+- **Principle of Least Privilege:** Grant users only the minimum permissions necessary for their role
+
+**WeWeb-specific tips:**
+- Store user roles in your backend database, not in WeWeb's local storage
+- Use WeWeb's conditional logic to show/hide UI elements based on user roles
+- Create reusable permission checking functions in WeWeb's custom functions
+- Set up role-based navigation menus and page access
+- Use WeWeb's workflow conditions to restrict form submissions and actions based on user roles
+
+---
+
+## Additional Security Considerations
+
+### Before Launch Checklist:
+- [ ] Test all authentication flows (login, logout, password reset)
+- [ ] Verify that unauthenticated users cannot access protected content
+- [ ] Test user impersonation scenarios (can users access other users' data?)
+- [ ] Validate that sensitive operations require appropriate permissions
+- [ ] Check that error messages don't leak sensitive information
+- [ ] Ensure HTTPS is enforced for all communications
+- [ ] Review and test all API endpoints for proper authorization
+- [ ] Validate input sanitization to prevent injection attacks
+- [ ] Test session management and timeout behaviors
+- [ ] Review third-party integrations for security compliance
+
+### Ongoing Security Practices:
+- Regular security audits and penetration testing
+- Monitor authentication logs for suspicious activity
+- Keep all dependencies and frameworks updated
+- Implement proper backup and disaster recovery procedures
+- Regular review and update of user permissions and roles