Secrets Management Procedure

1. Purpose

The Secrets Management Procedure defines how the organization identifies, creates, stores, uses, shares, rotates, monitors, and securely disposes of sensitive authentication and cryptographic information.

The objective is to prevent unauthorized access, accidental disclosure, misuse, and long-term exposure of secrets.

Core Principle

Discover → Classify → Store Securely → Restrict Access → Use Safely → Monitor → Rotate → Revoke → Dispose → Verify

2. Scope

This procedure applies to secrets used by:

Employees
Contractors
Developers
IT administrators
Security personnel
DevOps teams
Cloud administrators
Applications
APIs
Service accounts
CI/CD pipelines
Infrastructure
Databases
Third-party integrations

It covers secrets stored or used in:

AWS/Azure/GCP
Cloud applications
SaaS platforms
Source-code repositories
CI/CD systems
Databases
Servers
Containers
Kubernetes
Infrastructure-as-Code
Developer workstations
Security tools
API integrations
Backup systems
Third-party services

3. What Is a Secret?

A secret is sensitive information that can provide authentication, authorization, access, or cryptographic capability.

Examples include:

Passwords
API keys
Access tokens
Refresh tokens
OAuth client secrets
Database passwords
SSH private keys
TLS/private certificates
Encryption keys
Cloud credentials
AWS access keys
Service-account credentials
CI/CD credentials
Webhook secrets
Signing keys
Recovery codes
VPN credentials
Third-party integration credentials

Not every sensitive value is necessarily a secret. The organization should assess whether disclosure could enable unauthorized access, impersonation, privilege escalation, or cryptographic compromise.

4. Secrets Management Principles

The organization should follow these principles:

Least Privilege

A secret should provide only the permissions required for its intended purpose.

Need-to-Know

Only authorized people, applications, or services should access a secret.

Centralized Management

Secrets should be stored in approved secrets-management systems where practical.

No Hard-Coding

Secrets must not be embedded directly into source code.

No Plain-Text Storage

Secrets must not be stored in unsecured documents, spreadsheets, tickets, or chat.

Limited Lifetime

Secrets should have an appropriate expiry or rotation mechanism where supported.

Individual Accountability

Human access to secrets should be attributable to an individual where practical.

Rapid Revocation

The organization should be able to revoke compromised secrets quickly.

5. Secrets Lifecycle

The organization should manage secrets throughout their lifecycle:

Requirement → Creation → Registration → Secure Storage → Access → Use → Monitoring → Rotation → Revocation → Disposal

A secret should not exist indefinitely without a defined owner and purpose.

6. Secrets Identification

When a new system, application, project, integration, or infrastructure component is created, the project team should identify whether secrets are required.

Questions include:

What secret is required?
Why is it required?
Who or what will use it?
What system will store it?
What permissions does it provide?
What information can it access?
Who owns it?
How long is it required?
How will it be rotated?
How will it be revoked?

7. Secrets Classification

Secrets should normally be treated as highly sensitive information.

Examples:

Secret	Typical Classification
Production database password	Restricted
AWS privileged credential	Restricted
Encryption private key	Restricted
API key	Restricted
OAuth client secret	Restricted
Service-account credential	Restricted
CI/CD deployment credential	Restricted
Development test credential	Confidential/Restricted depending on risk
Public API identifier	Not necessarily a secret

Classification should consider actual security impact and organizational requirements.

8. Secrets Ownership

Every important secret should have an identified owner.

The owner should be responsible for:

Business purpose
Appropriate permissions
Access requirements
Rotation requirements
Review
Revocation
Incident response
Retirement

The technical custodian may manage the secret operationally but does not necessarily own the business risk.

9. Approved Secrets Storage

Secrets should be stored in approved secure mechanisms such as:

AWS Secrets Manager
AWS Systems Manager Parameter Store where appropriate
Azure Key Vault
Google Secret Manager
Enterprise password managers
Approved privileged-access platforms
Approved CI/CD secret stores
Hardware security modules where required

The selected mechanism should provide security appropriate to the secret’s sensitivity.

10. AWS Secrets Management

For AWS environments, secrets should be managed using appropriate AWS security services.

Example:

Application → IAM Role → AWS Secrets Manager → Database Credential

The application should retrieve the required secret using an authorized workload identity rather than embedding the database password in application code.

Security controls may include:

IAM permissions
KMS encryption
Resource policies
CloudTrail logging
Secret rotation
Least privilege
Environment separation
Access monitoring

11. Secret Creation

Secrets should be generated using approved secure mechanisms.

Where possible:

Use cryptographically secure random generation.
Avoid manually created predictable passwords.
Avoid reuse of secrets.
Use appropriate secret length.
Avoid predictable naming/content.
Record ownership and purpose.
Store directly in the approved secrets-management system.

Secrets should not be generated in public online tools or unapproved applications.

12. Human Passwords

Human passwords should be managed according to the Authentication & Password Policy.

Employees should use:

Unique passwords
Approved password managers
MFA where required
Secure password-reset mechanisms

Human passwords should not be placed into application configuration files or source code.

13. Application Secrets

Application secrets may include:

Database credentials
API keys
OAuth secrets
Encryption keys
Service credentials
Signing secrets

Applications should retrieve secrets securely at runtime or through an approved secure configuration mechanism.

Secrets should not be hard-coded in:

Source files
Configuration files committed to repositories
Dockerfiles
Infrastructure-as-Code repositories
JavaScript bundles
Mobile application packages
Documentation

14. Source Code and Git Repositories

Secrets must not be committed to source-code repositories.

Developers must not place credentials in:

.env files committed to Git
Source code
Configuration files
YAML/JSON configuration committed to repositories
Terraform files containing real secrets
Dockerfiles
Kubernetes manifests containing unprotected credentials

Where environment files are required for development, they should be excluded from source control and handled using approved secure methods.

15. Secret Scanning

The organization should use secret-scanning mechanisms where appropriate.

Examples include:

Git repository secret scanning
CI/CD secret scanning
Developer security tools
Code scanning
Pre-commit scanning
Cloud security monitoring

If a secret is discovered in source code, it should be treated as potentially compromised.

Deleting the secret from the latest version of the repository does not necessarily eliminate historical exposure.

16. Exposed Secret Response

If a secret is accidentally committed, exposed, emailed incorrectly, or otherwise disclosed:

Detect → Contain → Revoke → Replace → Investigate → Verify → Record

Immediate actions may include:

Identify the affected secret.
Determine where it was exposed.
Revoke or disable it.
Generate a replacement.
Update dependent systems.
Review access/activity logs.
Determine whether unauthorized use occurred.
Assess whether a security incident occurred.
Remove the exposed secret from systems where appropriate.
Record corrective actions.

The original secret should not simply be considered safe because the visible copy was deleted.

17. Access to Secrets

Access should be granted based on:

Business need
Role
System responsibility
Information classification
Privilege
Environment
Risk

Access should be:

Least privilege
Need-to-know
Individually attributable where practical
Time-limited where appropriate
Reviewed periodically

18. Human Access to Production Secrets

Human access to production secrets should be restricted.

Where practical:

Use privileged access controls.
Require MFA.
Use named identities.
Require approval for sensitive access.
Log access.
Limit access duration.
Review access periodically.

Employees should not routinely copy production secrets to their personal computers.

19. Application Access to Secrets

Applications should receive only the secrets they require.

Example:

An application requiring access to one RDS database should not receive credentials allowing access to every production database.

The organization should use:

Workload identities
IAM roles
Managed identities
Least-privilege policies
Secret-specific permissions
Environment-specific access

where technically appropriate.

20. CI/CD Secrets

CI/CD systems may require:

Cloud deployment credentials
Repository tokens
Package repository credentials
Signing credentials
Deployment keys
API credentials

These secrets should be stored using the CI/CD platform’s approved secret-management capability or an integrated secrets-management system.

Secrets should:

Not appear in pipeline output.
Not be printed in logs.
Not be included in build artifacts.
Have minimum required permissions.
Be rotated appropriately.

21. Container Secrets

Secrets must not be embedded directly into container images.

Avoid:

Dockerfile
ENV DATABASE_PASSWORD=...

or similar approaches containing real credentials.

Use approved runtime secret mechanisms instead.

Examples include:

AWS Secrets Manager
Kubernetes Secrets with appropriate protection
External Secrets mechanisms
Cloud workload identity
Platform-managed secret injection

22. Infrastructure-as-Code

Infrastructure-as-Code should not contain plaintext production secrets.

Examples include:

Terraform
CloudFormation
Ansible
Kubernetes manifests
ARM/Bicep
Deployment scripts

Where sensitive values are required, use appropriate secret references or secure variable mechanisms.

23. Database Credentials

Database credentials should:

Be unique.
Have minimum required permissions.
Be stored securely.
Not be embedded in applications.
Be rotated according to risk and technical capability.
Be revoked when no longer required.

Separate credentials should be used for different environments where appropriate.

Example:

Development ≠ Testing ≠ Production

24. API Keys

API keys should be:

Issued only when required.
Scoped to minimum permissions.
Restricted by environment where possible.
Stored securely.
Monitored where appropriate.
Rotated/revoked according to risk.
Removed when no longer required.

Where supported, use stronger authentication mechanisms such as short-lived tokens or workload identity instead of long-lived API keys.

25. SSH Keys

SSH private keys should be:

Protected from unauthorized access.
Stored securely.
Associated with an identified owner.
Protected with appropriate authentication.
Reviewed periodically.
Revoked when no longer required.

Private keys must never be committed to source repositories.

26. Encryption Keys

Cryptographic keys require additional protection.

The organization should:

Restrict access.
Separate key-management responsibilities where appropriate.
Protect keys from unauthorized export.
Monitor key-management activity where practical.
Rotate keys according to risk and applicable requirements.
Revoke/retire keys securely.
Maintain appropriate recovery procedures.

Where appropriate, use managed key-management services such as AWS KMS or equivalent services.

27. TLS and Private Certificates

Private certificates and associated private keys should be protected as secrets.

Controls should include:

Restricted access
Secure storage
Expiration monitoring
Renewal
Revocation where required
Protection from unauthorized export

Certificate inventories should identify important certificates and their owners.

28. Secret Rotation

Secrets should be rotated based on:

Risk
Credential type
System capability
Exposure
Business requirements
Regulatory/contractual requirements
Security incidents

Rotation should be performed when:

A secret is compromised.
An authorized user leaves and the secret is shared or otherwise affected.
A third party’s access ends where applicable.
Ownership changes.
A system is decommissioned.
Security requirements change.
A secret reaches its defined lifetime.

Rotation frequency should be defined based on risk rather than using one universal interval for every secret.

29. Automated Secret Rotation

Where supported, automated rotation should be considered for:

Database credentials
API credentials
Service credentials
Cloud credentials
Certificates
Other machine secrets

Automated rotation should be tested to ensure applications continue operating securely after rotation.

30. Secret Expiry

Where technically supported, secrets should have:

Expiry dates
Rotation dates
Ownership
Business purpose
System association

Expired or unused secrets should be disabled or removed.

31. Third-Party Secrets

Third-party credentials should be managed securely.

Examples:

Payment gateway keys
CRM integration tokens
Email-service credentials
Customer API credentials
Cloud-provider credentials
Security-vendor credentials

The organization should document:

Provider
Purpose
Owner
Permissions
Environment
Expiry
Rotation process
Data accessed
Contractual requirements

32. Customer-Provided Secrets

Customer-provided credentials should be handled carefully.

They should:

Be received through approved channels.
Not be stored in ordinary documents or email unnecessarily.
Be restricted to authorized personnel.
Be used only for the approved purpose.
Be protected during storage.
Be returned/deleted when no longer required.
Be handled according to contractual requirements.

33. Secrets in Logs

Applications and systems must not unnecessarily record secrets in logs.

Developers and administrators should ensure that logs do not expose:

Passwords
API keys
Access tokens
Session tokens
Private keys
Database credentials
Authorization headers
Recovery codes

Where possible, sensitive values should be masked or redacted.

34. Secrets in Monitoring and Error Messages

Secrets must not appear unnecessarily in:

Error messages
Debug output
Monitoring dashboards
Support tickets
Screenshots
Incident reports
Performance traces
Application telemetry

Production debugging should be performed using approved controlled methods.

35. Secrets in AI Tools

Employees and developers must not enter secrets into unauthorized AI tools.

This includes:

Passwords
API keys
Tokens
Private keys
Cloud credentials
Production database credentials
Customer credentials
Encryption keys
Security credentials

Approved AI tools and approved use cases should follow the organization’s AI Acceptable Use Policy.

36. Secrets in Development and Testing

Development and test environments should not use production secrets unless explicitly authorized and appropriately protected.

Where possible:

Use synthetic credentials.
Use separate environments.
Use test accounts.
Use test API keys.
Use non-production databases.
Avoid production customer data.

Production credentials should never be copied into development environments for convenience.

37. Secret Sharing

Secrets should not be shared through:

Email
Chat
Public links
Spreadsheets
Source repositories
Ticket comments
Personal cloud storage
Unapproved file-sharing services

Where sharing is genuinely required, use an approved secure mechanism and restrict access to the intended recipient.

38. Emergency Secret Disclosure

If a secret must be disclosed during an emergency:

Verify the recipient.
Confirm the business/security reason.
Use an approved secure channel.
Limit the secret’s permissions where possible.
Record the event where appropriate.
Rotate the secret after the emergency if required.

Emergency sharing should not become the normal operating procedure.

39. Secret Revocation

Secrets must be revoked when:

No longer required.
Compromised.
Owner leaves.
System is retired.
Integration is terminated.
Access is no longer authorized.
Contract ends.
Secret has reached its approved lifetime.

Revocation should be verified.

40. Secret Disposal

When a secret is retired:

Disable/revoke it.
Remove it from active systems.
Remove unnecessary copies.
Remove exposed versions from appropriate repositories where feasible.
Update the relevant register.
Record evidence where required.

For cryptographic material, disposal should follow applicable key-management requirements.

41. Secrets Register

Important secrets should be tracked through an appropriate register.

The register may contain:

Field	Description
Secret ID	Unique identifier
Secret Type	API key, DB credential, token, certificate, etc.
System/Application	Associated system
Environment	Dev/Test/Production
Owner	Business/security owner
Technical Custodian	Person/team managing it
Purpose	Why it exists
Access Scope	Resources/permissions
Classification	Confidential/Restricted
Creation Date	Date created
Expiry Date	If applicable
Rotation Frequency	Defined requirement
Last Rotation	Last rotation date
Next Rotation	Planned rotation
Storage Location	Approved secret store
Related Asset	Asset ID
Related Risk	Risk ID
Status	Active/Expired/Revoked
Evidence	Supporting record

The actual secret value must never be stored in the register.

42. Secret Access Review

Periodic review should verify:

Does the secret still have a business purpose?
Is the owner still valid?
Is the access scope still appropriate?
Are permissions excessive?
Is the secret still required?
Is MFA/strong authentication used where applicable?
Has the secret expired?
Does the secret require rotation?
Are there unnecessary copies?
Is the storage mechanism still approved?

43. Secret Discovery and Reconciliation

The organization should periodically identify unknown or unmanaged secrets.

Possible sources include:

Source repositories
CI/CD systems
Cloud environments
Application configuration
Containers
Infrastructure-as-Code
Developer environments
SaaS integrations
Password managers
Secret stores

Process

Discover → Validate → Identify Owner → Assess Risk → Secure/Rotate → Update Register → Verify

44. Incident Handling

A suspected secret compromise should be handled according to the organization’s Incident Response and Security Incident Management Procedures.

The response should consider:

What secret was exposed?
Where was it exposed?
Who could access it?
What permissions did it provide?
Was it used?
What systems could be affected?
Was customer or personal information accessible?
Should credentials be revoked immediately?
Is regulatory or contractual notification required?
What corrective action is necessary?

45. AWS SaaS Startup Example

A SaaS company operates its production environment on AWS.

Poor Approach

Application Code
      ↓
Hard-coded DB password
      ↓
Git Repository
      ↓
Production Database

Recommended Approach

Application
      ↓
AWS IAM Role
      ↓
AWS Secrets Manager
      ↓
RDS Credential
      ↓
Production Database

Additional controls may include:

IAM least privilege
KMS protection
CloudTrail logging
Secret rotation
Separate development/production secrets
Secret access monitoring
No credentials in Git
CI/CD secret protection
Periodic secret review

46. Secrets Management During Project Development

For a new application:

Requirements

Identify required credentials and secrets.

Design

Select approved secret-management mechanisms.

Development

Use non-production credentials.

Testing

Verify that secrets are not exposed through code, logs, containers, or CI/CD.

Deployment

Configure production secrets securely.

Operation

Monitor and rotate secrets.

Retirement

Revoke secrets when the application or integration is retired.

47. Roles and Responsibilities

Role	Responsibility
Secret Owner	Defines purpose, access and lifecycle
Security/ISMS	Defines requirements and monitors risks
IT/Cloud	Configures secure storage and access
Engineering	Prevents secrets from entering source code
DevOps	Protects CI/CD and deployment credentials
Application Owner	Ensures application secrets are appropriately managed
System Administrator	Protects administrative credentials
Employees	Protect secrets and report exposure
Procurement	Supports third-party credential requirements
Internal Audit	Independently verifies controls

48. Evidence

Potential audit evidence includes:

Secrets Register
AWS Secrets Manager configuration
IAM policies
KMS configuration
Secret-access logs
CloudTrail records
Secret rotation records
Credential-revocation records
Repository secret-scanning results
CI/CD configuration
Security incident records
Access reviews
Privileged-access reviews
Application configuration
Change records
Secret-management procedures
Training records

Actual secret values must never be provided to auditors as evidence.

49. Exceptions

Exceptions to this procedure should be:

Documented
Risk assessed
Approved
Assigned to an owner
Supported by compensating controls where appropriate
Time limited where practical
Periodically reviewed

Examples:

Legacy application unable to integrate with a secrets manager
Customer-mandated credential mechanism
Technical limitation in a third-party platform

50. Metrics

The organization may monitor:

Number of secrets
Number of unmanaged secrets
Secrets approaching expiry
Secrets overdue for rotation
Secrets detected in source repositories
Number of exposed secrets
Average time to revoke exposed secrets
Percentage of production applications using approved secret stores
Number of secret-related incidents
Number of secrets without identified owners

Metrics should be used to identify improvement opportunities rather than simply to demonstrate activity.

51. Startup-Friendly Implementation

A startup does not need a complicated secrets-management platform on day one.

A practical minimum model is:

1. Identify

Find passwords, API keys, tokens, certificates, cloud credentials, and service credentials.

2. Centralize

Move important secrets into an approved secret store.

3. Remove Hard-Coding

Scan source code and CI/CD repositories.

4. Restrict

Apply least privilege.

5. Monitor

Track access to important secrets where technically possible.

6. Rotate

Define risk-based rotation and immediate rotation after compromise.

7. Review

Review ownership, access, expiry, and necessity.

8. Revoke

Remove secrets when no longer required.

52. Quick Audit Checklist

Identification

Important secrets identified
Secret owners assigned
Purpose documented
Production secrets identified

Storage

Approved secret store used
No plaintext storage
No secrets in source code
No secrets in container images
No secrets in IaC repositories

Access

Least privilege
Need-to-know
Human access controlled
Application access controlled
Privileged access protected

Rotation

Rotation requirements defined
Compromised secrets can be rotated quickly
Expired secrets identified
Unused secrets revoked

Monitoring

Secret access monitored where appropriate
Secret scanning implemented where practical
Logs do not unnecessarily expose secrets

Lifecycle

Creation controlled
Ownership maintained
Access reviewed
Secrets revoked when no longer required
Disposal verified

Incident Response

Secret compromise process defined
Immediate revocation possible
Replacement process defined
Incident escalation defined
Evidence retained

53. Relationship with Other ISMS Documents

This procedure connects with:

Authentication & Password Policy
Identity Management Policy
Access Control Policy
Privileged Identity Management Procedure
Privileged Access Register
Service Account Register
Identity Register
User Account Management Procedure
Joiner-Mover-Leaver Procedure
Access Revocation Checklist
Secure Development Checklist
Security Testing Checklist
Project Security Requirements
Cloud Asset Inventory
Information Classification Policy
Data Handling Guidelines
AI Acceptable Use Policy
Incident Response Plan
Security Incident Management Procedure
Risk Assessment Procedure
Supplier Security Assessment
Third-Party Access Procedure

Control Chain

Secret Requirement

→ Secret Creation

→ Secure Storage

→ Access Control

→ Secure Use

→ Monitoring

→ Rotation

→ Revocation

→ Evidence

→ Continual Improvement

54. ISO 27001 Connection

This procedure supports applicable ISO/IEC 27001 requirements and controls relating to:

Authentication information
Identity and access management
Access control
Privileged access
Cryptographic controls
Secure development
Configuration management
Logging and monitoring
Cloud security
Supplier relationships
Incident management

The specific controls applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability (SoA).

55. Final Audit Trail

For an important production secret, the organization should be able to demonstrate:

Why does the secret exist?

→ Who owns it?

→ What system uses it?

→ What permissions does it provide?

→ Where is it stored?

→ Who or what can access it?

→ Is access least-privilege?

→ How is it protected?

→ How is access monitored?

→ When is it rotated?

→ What happens if it is compromised?

→ When is it revoked?

→ How is disposal verified?

→ What evidence demonstrates that the lifecycle was controlled?

Final Principle

A secret should never be treated as just a password or configuration value. It is an access capability. Know what it protects, who or what can use it, where it is stored, how it is rotated, and how quickly it can be revoked if compromised.