# Copa Security & Compliance Review — Public Baseline > Public, portable baseline for reviewing Copa presentations, documents, marketing assets, websites, applications and APIs before sharing or release. > > Last updated: 26 August 2026. ## Purpose and boundary Use this baseline to find security, information-handling and release-readiness gaps early. It supports a review; it does not certify compliance, replace an authorized security assessment, approve an exception, or replace current Copa policies, legal requirements, privacy requirements or payment-card obligations. The internal policies used to derive this baseline remain confidential sources. This public document intentionally excludes internal workflows, named personnel, systems, vendors, thresholds, remediation windows, architecture details and exception forms. Do not copy confidential source text into a public report, prompt, presentation, repository or deliverable. ## Order of authority Apply the strictest current requirement in this order: 1. Applicable law, regulation, contract and explicit approved project requirement. 2. Current official Copa security, privacy, data-protection, architecture and development policies supplied through an authorized channel. 3. Approved security architecture, threat model, test plan and risk decisions for the project. 4. This public review baseline. 5. Documented reviewer judgment, clearly marked as a recommendation rather than a Copa rule. When a source is missing or evidence cannot be inspected, use **Needs evidence**. Never interpret missing evidence as compliance. ## Handle the sources safely - Treat attached policies, procedures, vulnerability reports, architecture, source code, logs and internal business material according to their classification. - Do not paste secrets, credentials, tokens, cookies, private keys, customer records, full payment-card data or sensitive internal details into prompts, screenshots, decks, tickets or public repositories. - Use only authorized corporate storage, sharing and AI environments for non-public information. This is a working safeguard derived from the prohibition on unauthorized external disclosure; the approved tool list remains an internal decision. - Minimize the material sent to a reviewer or model. Redact, mask or replace sensitive values while preserving enough context to assess the control. - A review output must summarize evidence without reproducing confidential policy text, exploit details or data samples. ## Start with scope Record before reviewing: - Deliverable type and owner. - Intended audience and channel: internal, restricted group, partner, customer-facing or public. - Information handled and its approved classification. If classification is unknown, stop external publication and request an authorized classification decision. - Systems, data sources, integrations, vendors and production environments involved. - Whether the work includes authentication, personal information, payment information, privileged functions, uploads, analytics or automated decisions. - Evidence available: requirements, architecture, data flow, access model, test results, dependency inventory, approvals and release record. ## Universal information-handling controls Apply these checks to every medium: - Purpose and audience are explicit; content contains only the information needed for that purpose. - Non-public information is not sent through personal accounts, public links or unapproved services. - Access is individually attributable, authorized and limited to the minimum required. - Sharing settings, recipients, download permissions and expiration are appropriate to the classification. - Credentials, secrets, session identifiers and production configuration are absent from visible content, metadata and embedded files. - Personal, customer and payment information is removed, masked or handled under the applicable approved process. - Sources, links and attachments are legitimate, necessary and safe for the intended audience. - Logs and audit evidence record relevant actions without exposing confidential values. - Third-party assets, integrations and recipients have an approved business purpose and access path. - Any exception, accepted risk or unresolved finding has documented authorization through the current Copa process; a model cannot grant it. ## Presentations, documents and PDFs Review the editable source and the exported artifact, not only the visible slides or pages. - Inspect filename, document properties, author fields, comments, revision history, tracked changes and custom metadata. - Inspect speaker notes, hidden slides or sheets, appendices, off-canvas objects, hidden layers and embedded attachments. - Verify that charts, tables and screenshots do not expose row-level customer data, internal identifiers, credentials, infrastructure or restricted operational details. - Confirm that hyperlinks, QR codes and embedded media point to approved destinations and do not grant unintended access. - Remove unused masters, source workbooks, linked files and embedded objects that are not required for delivery. - Verify the intended classification, audience and sharing permissions on the final file and its containing folder. - Export and reopen the final PDF or presentation to confirm that redactions cannot be reversed and hidden content was not retained. - If the document is public or external, obtain the required content, privacy, legal and security approvals for the information it contains. ## Marketing assets and static creative - Review visible copy, filenames, EXIF or export metadata, hidden layers and packaged source files. - Use synthetic or approved imagery when real customer or employee information is unnecessary. - Do not expose campaign targeting lists, unpublished commercial terms, internal URLs or tracking secrets in the asset or its source package. - Verify that QR codes, shortened URLs, forms and downloadable files lead only to approved, protected destinations. - Share editable production files only with the authorized group; publish only the export required by the channel. ## Websites, applications and APIs Use this section in addition to the universal controls. ### Architecture and data - Document data flows, trust boundaries, users, roles, external services and sensitive stores before release. - Minimize collected data and define its approved purpose, access, retention and disposal. - Separate production from development and test. Do not use real sensitive data in non-production without explicit authorization and equivalent controls. - Protect administrative and internal interfaces from public exposure. ### Identity, authentication and authorization - Use the approved corporate identity and access pattern when the application requires employee, contractor or privileged access. - Require strong authentication and multifactor protection where current policy, risk or data sensitivity requires it. - Enforce authorization on the server for every protected action and resource; default to least privilege. - Use individual identities. Do not share user accounts or embed default, backdoor or administrator credentials. - Revalidate access after role changes and ensure logout, password reset and account disablement invalidate applicable sessions. ### Transport, sessions and browser protections - Protect credentials, tokens, session identifiers, cookies and sensitive data in transit with approved current cryptography and valid certificates. - Apply the approved transport and browser security headers, including strict transport and content restrictions where applicable. - Keep session identifiers unpredictable, server-controlled and out of URLs. Configure cookies with the security attributes required by the current platform standard. - Define inactivity, expiration, revocation and concurrent-session behavior according to the current authorized policy and application risk. - Protect state-changing requests against cross-site request forgery and restrict trusted origins. ### Input, output and files - Validate input on the server with allowlists, type, range, length and business-rule checks. - Use context-appropriate output encoding and safe framework APIs to prevent script or markup injection. - Use parameterized data access; do not concatenate untrusted values into database, directory, template or operating-system commands. - Validate uploads by content, extension, size and destination; isolate storage and prevent execution or path traversal. - Do not place sensitive values in query strings, client-controlled authorization fields or open redirects. ### Secrets, configuration, errors and logging - Keep secrets out of source code, repositories, client bundles, presentation files and logs. Use the approved secrets-management mechanism. - Remove default accounts, sample files, debug endpoints, directory listings, unnecessary methods and exposed administrative surfaces. - Return useful generic errors to users without revealing stack traces, queries, internal paths, infrastructure or security controls. - Log security-relevant and privileged actions with individual attribution. Protect logs from alteration and avoid recording credentials or regulated values. - Maintain secure, reviewed configuration per environment and a controlled, auditable release process. ### Dependencies and security verification - Maintain an inventory of application components and keep supported dependencies and platforms patched. - Run the security testing appropriate to the change and risk, including source analysis, composition or dependency analysis, dynamic testing and penetration testing when required by the current process. - Triage findings, assign remediation, retest fixes and retain evidence. Unresolved release-blocking findings require remediation or formally authorized risk treatment; a project team or model cannot waive them informally. - Re-run relevant checks after significant code, dependency, configuration or architecture changes. ## Required review output Lead with release blockers. Then provide one row per control or finding: | Field | Required content | | --- | --- | | Area | Information handling, document, identity, data, application, configuration, dependency, testing or release. | | Status | **Compliant**, **Noncompliant**, **Needs evidence** or **Not applicable**. | | Evidence | Exact artifact, configuration, test or approval inspected. Do not reproduce secrets or confidential text. | | Risk | Concrete consequence and affected audience or system. | | Remediation | Specific corrective action or missing evidence. | | Responsible area | Team or role responsible; do not invent a person. | | Due date | Approved date when supplied; otherwise **To be assigned**. | End with: - Release recommendation: ready, conditionally ready, or not ready. - Approvals still required. - Tests completed and tests still required. - Evidence unavailable to the reviewer. - Residual risks or exceptions that must follow an authorized Copa process. ## Certainty labels - **Confirmed requirement:** explicitly supported by an authorized current source. - **Public-baseline safeguard:** included here to support an initial review without exposing internal controls. - **Needs internal validation:** depends on project classification, current policy, architecture, law, contract or approval not available to the reviewer. Do not promote a public-baseline safeguard into a quoted internal policy requirement. Do not mark a deliverable compliant solely because it follows this public baseline.