Best Practices - Cloud Platforms & SaaS Integrations
What Are Cloud Platforms & SaaS Integrations?
Cloud platforms and Software-as-a-Service (SaaS) applications often support third-party integrations, plugins, APIs, extensions, and automation features. These capabilities can improve productivity and system interoperability, but they can also introduce security and privacy risks if they are not carefully scoped, monitored, and retired when no longer needed.
Common Risks
| Category | Description | Key Controls (At a Glance) |
|---|---|---|
Over-Privileged Access | Integrations may request broad or administrative access beyond what is required to function. | Apply least privilege; scope permissions; avoid tenant-wide or admin-level access. |
Data Leakage | Confidential data may be shared with third parties whom are not authorized by the University. | Handle Level 2+ data cautiously; limit the number of integrations by functional requirement. |
Shadow Integrations | Integrations added outside standard processes may go unnoticed and unmanaged. | Centralize controls for authorizing new integrations. Maintain an inventory and review regularly. |
Orphaned Integrations | Integrations may continue accessing data after projects or contracts end. | Revoke access; remove integrations; update inventories. |
Retention Misalignment | Data stored in cloud platforms may be retained longer than permitted if retention, archiving, or deletion are not actively managed. | Apply records schedules; archive inactive data; delete when permitted. |
Inadequate Off-Boarding | Failure to delete or verify deletion of Harvard data leaves data outside University control. | Plan off-boarding; require NIST 800-88-aligned deletion; obtain confirmation. |
Limited Visibility | Without logs or audit trails, integration activity is difficult to detect or investigate. | Enable audit logs; monitor administrative actions. |
Unvetted Vendors | Cloud services or integrations not reviewed by IT, Privacy, or Procurement may lack adequate safeguards or contractual protections. | Use approved or contracted vendors; involve Procurement and SPSOs early. |
Note:
The “Key Controls (At a Glance)” column is intended as a quick reference. Detailed expectations and implementation guidance are described in the Best Practices sections below.
General Best Practices
Use Contracted and Vetted Services
- Prefer cloud platforms, SaaS tools, and integrations already reviewed and approved by your School or IT department.
- Any service accessing Level 2 and above data must have appropriate contractual protections in place.
- Do not enable integrations that process sensitive or regulated data without consulting Procurement, your SPSO, or PrivSec.
Apply Least Privilege by Default
- Grant only the minimum permissions required for an integration to function.
- Prefer:
- Read-only or scoped access
- User-level permissions over tenant-wide or domain-admin access
- Be especially cautious with integrations requesting access to mailboxes, calendars, files, or administrative settings
Verify Identity, Authentication & Secrets Handling
- Use supported authentication methods (SSO, OAuth, scoped tokens).
- Avoid long-lived credentials or shared secrets.
- Protect administrative access with MFA.
- Rotate API keys and tokens regularly and remove them when no longer needed.
Maintain Visibility and Logging
- Enable audit and activity logs where available, including:
- Data access
- Configuration changes
- Administrative actions
- Retain logs according to system requirements and data sensitivity.
- Review logs periodically for unusual or unexpected activity.
Align Cloud Data with Retention, Archiving & Classification Requirements
- Identify what University data is stored or generated in the platform and its risk classification.
- Apply Harvard’s Records Schedules to determine required retention periods.
- When data is no longer needed for active use but must still be retained, archive or restrict access rather than leaving it broadly available.
- When retention requirements are met, delete data securely, including derived files, exports, and copies where feasible.
- Do not rely on backups or snapshots as a substitute for records retention or archiving.
Review Integrations Regularly
- Review all active integrations at least annually, and sooner when:
- The vendor changes functionality, ownership, or privacy practices
- Permissions expand
- The business need changes
- A security incident or advisory occurs
- Confirm the original purpose still exists and access remains appropriate.
- Update asset inventories.
Plan for Secure Off-Boarding
- Revoke access tokens, API keys, and permissions.
- Remove the integration from the platform.
- Retrieve Harvard data securely if required.
- Require vendors to delete all Harvard data, including backups and replicas, using NIST SP 800-88-aligned methods.
- Request written confirmation or a Certificate of Data Destruction when appropriate.
- Update inventories and documentation.
Treat Integrations as Part of the Vendor Lifecycle
Integrations are not “set-and-forget.” They should be:
- Onboarded thoughtfully
- Monitored during use
- Reassessed as risk changes
- Off-boarded securely
Related Resources
- Minimum Security Standards – Common Controls; Vendor Off-Boarding & Data Destruction
- Harvard Records Schedules – Retention and archival requirements
- Generative AI Guidelines – Data classification expectations (Level 2 and above)