Внутреннее SLA - это, чаще всего, соглашение между ИТ и другим бизнес-отделом, например, отделом по продажам и маркетингу или отделом персонала. Однако, внутренний SLA может также существовать между другими отделами, не связанными с ИТ. Например, отделы сканирования, почты, поддержки клиентов, и составления счетов могут иметь SLAs с другими областями бизнеса, которым они предоставляют сервисы.
Хотя внутреннее SLA между двумя отделами одной организации редко имеет юридические последствия, внутреннее SLA описывает отношения, ожидания, и расписание предоставления сервиса. Оно представляет соглашение между двумя сторонами. Должны быть приложены все усилия для достижения уровней сервиса, зарегистрированных и подписанных в нем. Внутренние стороны ответственны за то, чего они достигнут или не достигнут, как определно в SLA. В организации могут быть последствия, если не выполнен согласованный сервис, даже при том, что этот документ не является юридическим контрактом. Например, может пострадать статус ИТ, если возникли проблемы с платными услугами или если затраты на предоставление сервиса не могут быть оправданы.
Внутренние SLAs требуют администрирования их эксплуатации, отчетности обзора и оптимизации процесса. Эти функции могут выполняться различными ролевыми кластерами, которые организация считает подходящими для их выполнения, поскольку обязанности для администрирования могут быть определены SLO. Например, мониторинг и отчетность целевых параметров системного администрирования может проводиться функцией системного администрирования, а мониторинг и отчетность целевых параметров запросов на изменения может проводиться менеджером изменений. Сопоставление всех полученных данных для SLAs может быть ответственностью администратора уровня сервиса и членов кластера поддержки в командной модели MOF.
Дополнением к интервальному администрированию будет администрирование как результат изменений. Изменение в сервисном компоненте, сервисе или специализации бизнеса может произвести изменение непосредственно в SLA. Процесс контроля изменений должен быть применен ко всем документам SLA. Для этого полезно использовать контроль версий. Если в пределах организации возможно хранение SLA как CIs в CMDB, то SLA подпадут под процесс управления изменениями. Если SLA хранятся в другом формате, убедитесь, что полномочия для внесения изменений в них ограничены для гарантии их целостности. Удостоверьтесь, что они доступны в режиме «чтения» для всех заинтересованных сторон как в ИТ, так и в бизнесе.
