Build a review packet, not a security-engineering result.
Information Security Engineers develop and oversee security procedures and policies, build or upgrade security technology, design and implement controls, and may oversee assessment.1 Systems security engineering spans security requirements, design, verification, validation, and assurance across a lifecycle.2 Those are consequential activities. This safe workflow only organizes fictional or organization-approved minimum-necessary labels and hands unanswered questions to named authorities.
needs_review.Set a strict scope before any AI work.
Give the packet a fictional or approved scenario label, a stated purpose, and a named authority owner. Exclude system names, code, diagrams, configurations, credentials, identities, ticket text, test output, findings, security-tool output, customer data, and other private/security-sensitive material.
Register supplied labels without turning them into evidence.
For every supplied label, record its reference, owner, time/version, stated purpose, and type: requirement, control, test, or decision. Use only
supplied,unknown, orconflictingstatus. Never ask a model whether a design is secure or what it should do.Let AI organize, not inspect or engineer.
AI may format supplied labels, flag blank fields, group duplicates, and draft neutral questions. It must not inspect a system or repository, infer a threat/vulnerability, select a control, create a test result, or draw a security conclusion.
Preserve gaps as reviewer questions.
For every missing owner, time, source, approval, policy, or lifecycle gate, retain
unknown. Ask the named security-engineering owner which current process governs the missing fact; do not fill it from model inference.Route authority to the right owner.
Security engineering owns technical assessment; technical and system owners own implementation context; privacy, legal, and compliance own obligations; procurement owns vendor approval; risk owners accept risk; operations owns execution; records owners govern retention.
Stop at the review handoff.
Create only a local
needs_reviewreceipt. Do not issue a finding, edit a ticket, change code/configuration, select a requirement/control/test, approve an exception, deploy, purchase, communicate, or take any external action.
Three bounded roles. One human control point.
unknown or conflicting. No requirement, control, test, or risk conclusion.NIST's SSDF describes high-level secure-development practices that can be integrated into each SDLC implementation.3 A label packet is not a completed SSDF practice, a passing test, or a conforming security program.
Let AI prepare labels. Let authorized people control engineering.
| AI may prepare | Named human approval is required |
|---|---|
| Format supplied fictional or approved minimum-necessary labels. | Access, inspect, retrieve, upload, query, or analyze any system, repository, security tool, test environment, ticket, design, configuration, or record. |
| Preserve supplied reference, owner, time/version, stated purpose, type, and unknown/conflict labels. | Identify a threat or vulnerability; select/approve requirements, architecture, controls, configurations, tests, findings, exceptions, risk, residual risk, or readiness. |
| Draft neutral questions about missing authority or contradictory labels. | Claim verification, validation, compliance, authorization, or assurance; change code, a control, configuration, credential, record, or ticket; deploy; procure; or communicate. |
| Produce a local review-only receipt. | Approve a vendor/tool, make legal/privacy/compliance conclusions, accept risk, or take any external action. |
Five ways label prep quietly becomes unauthorized engineering.
| Mistake | Why it fails | Repair |
|---|---|---|
| “Choose the right control.” | Control selection is an engineering and risk decision. | Preserve the supplied labels and route selection to an authorized owner under the current process. |
| “Tell me whether this design is secure.” | It asks for an assessment from potentially sensitive or incomplete material. | Do not enter the design. Record the unknown and request an approved assessment path. |
| “Generate a passing security test.” | A generated result can be mistaken for verification or validation evidence. | Keep only the supplied test-reference label; authorized testing happens in an approved environment. |
| “Mark the risk accepted.” | Risk acceptance can bind owners and create legal, contractual, and operational consequences. | Mark acceptance authority and status unknown; name the accountable risk owner. |
| “Deploy the mitigation.” | Deployment is an external system change with reliability and security consequences. | Stop at the review packet. Authorized humans choose and execute any change through the current process. |
Design-Assurance Evidence Desk
Enter only fictional or organization-approved, minimum-necessary labels. This form stays in the browser and creates a review-only receipt; it does not send, save, inspect, query, or connect to anything.
What this manual is built on.
- O*NET OnLine: Information Security EngineersOccupational context; profile marked Bright Outlook Updated 2026. [1]
- NIST SP 800-160 Vol. 1 Rev. 1Systems security engineering context; final published November 2022. [2]
- NIST SP 800-218: Secure Software Development FrameworkSecure-development lifecycle context; Version 1.1 final published February 2022. [3]
- NIST AI 600-1: Generative AI ProfileVoluntary generative-AI risk-management context; published 2024 and page updated April 2026. [4]
Sources are evidence context, not permission to use private material, assess a system, choose a security action, or take an external action. Recheck them and controlling organization rules before any non-fictional use.
Where this guide fits.
Proposed links: the Information Security Analyst Security Signal Evidence Desk for pre-investigation handoffs, the Computer Systems Engineers and Architects Evidence Desk for broader architecture decisions, the Software Quality Assurance Analysts and Testers Manual for test and release evidence, the AI Agent Workflow Builder for least-privilege job cards, and the Occupation AI Workflow Guide Directory for the broader shelf. Use these related guides to keep each workflow's authority boundary clear.