# Log Requests via Zendesk ### Log Requests via Zendesk (Inspection / Review / Extraction) #### Purpose Provide a formal, traceable, and auditable process for log requests. Zendesk is the system of record for intake, approval, execution, and evidence. #### System of Record * Submit requests to: (creates a Zendesk ticket) * Tickets are routed to a restricted Log Review group * Access: CISO and CTO (and explicitly approved delegates only) * Slack is not an official channel (content can be changed/deleted). Slack may be used only for coordination; decisions/results must be recorded in the ticket. #### Definitions * Log inspection: Confirm if something happened (yes/no, counts, timestamps). * Log review: Analyze events and timeline (explain what happened and why). * Log extraction: Export/share log data (highest risk; requires explicit approval). #### Roles * Requester: Submits request with required details. * Approver (CISO/CTO): Approves/rejects and sets scope/conditions. * Executor (DevOps Engineering / Security): Performs log work and documents actions/results in the ticket. * Ticket Owner: Ensures completeness, tracks progress, ensures approvals and closure notes. #### Request Requirements (must include) * Request type: inspection / review / extraction * Reason / justification * System(s) in scope * Time window (start/end + timezone) * Identifiers (if relevant): request/correlation ID, session ID, user ID, IP, certificate serial, etc. * Requested output (summary, timeline, redacted snippet, export) * Sensitivity (personal data / secrets possible?) * Deadline / urgency If key info is missing, the Ticket Owner requests clarification in the ticket before work begins. #### Approval Rules (CISO/CTO) Approval is required before execution when: * The request involves log extraction/export * Logs may contain personal/sensitive data (including audit logs) * The request relates to security incidents, suspected abuse, fraud, insider concerns * The requester/executor is a solution partner/external team * The scope is broad (e.g., > 7 days, multiple systems) Approvals must be recorded in Zendesk as Approved / Approved with conditions / Rejected. #### Execution Workflow 1. Intake: Email to → Zendesk ticket in restricted group 2. Triage: Ticket Owner validates scope/priority and determines if approval is required 3. Approve: CISO/CTO approves and defines constraints (scope, timeframe, allowed output) 4. Assign (“Tagging”): CISO/CTO tags named individuals or the DevOps group to execute 5. Execute: Executor performs log work and records: 6. systems accessed, timeframe, query/filters (as appropriate) 7. findings summary and limitations (e.g., retention gaps) 8. Evidence & Response: Evidence is attached or securely linked; response posted in ticket 9. Close: Ticket closed with closure notes (who approved/executed, what was shared, where evidence is stored, completion date) #### Data Handling Rules * Only the restricted group may access these tickets. * Minimize exposure: share only what is necessary to answer the request. * Never share: secrets/tokens/private keys, full auth material, unnecessary personal data. * Raw log exports are only allowed when explicitly approved and necessary. * When personal data is involved, document the lawful basis/justification briefly in the ticket. #### Email Template (Requester) To: \ Subject: Log Request — \[System] — \[Time window] * Type (inspection/review/extraction): * Reason/justification: * System(s): * Time window (timezone): * Identifiers: * Requested output: * Sensitivity (personal data/secrets possible?): * Deadline/urgency: * Contact person: --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.devland.is/technical-overview/log-management-policy/log-requests-via-zendesk.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.